Hello everybody from the Structured Data Across Wikimedia team!

We are currently investigating a number of visual improvements to Special:Search, to enable users to better find the information they are looking for. This is part of a greater initiative that we are conducting, called “Search Improvements”, and we are interested in hearing your feedback.

What do we want to do?

As you will see, most of the proposed changes are graphical improvements to the current way Special:Search looks like. Our goal is to provide better context and better layout for casual readers who want to use the Wikipedia search page, as well as promote awareness for Wikipedia’s sister projects by rearranging the “sister projects” search section.

In particular, we want to:

• Add an article thumbnail to search results to allow for better scanning of the content
• Add namespace tags in front of the article to better distinguish between page types
• Rearrange the sister search section for better context and awareness
• Collapse advanced search options by default to give more focus on results
• Restyle an article's metadata to put more focus on the content
• Moving the “no article found” message to a better position
• Change the color of the “did you mean” suggestion from red to blue (as red is more appropriate for missing articles)
  • The same will happen with the “Show results for” message

By clicking on the blue links, you can see a mockup of the proposed changes. You can also see all mockups at a glance by visiting the Search Improvements project page on Mediawiki.org.

What are we asking you?

We want to hear from you about these proposed changes. None of these suggestions is currently set into stone, and before deploying them we want to hear your opinion about them.

More specifically, we would like to know:

• What do you think about the approach that we outlined above?
• Do you think that any of these changes can affect the contribution flow? If yes, how?
• Do you think that these changes can improve the experience of new users or casual readers?

Your opinion is important to us, and we want to use it to inform these changes before we eventually deploy them, if there is feedback to do so from all communities.

How can you give feedback?

You can reply to this message here (please remember to ping User:Sannita (WMF) when you do) or on Mediawiki.org. We plan to keep this consultation going for around three weeks, from today until July 10, 2022.

We are also planning on hosting an office hour on June 28 at 15:00 UTC (link to the meeting), where you can ask questions and directly reply to the team about the proposed changes.

Hope to hear from you! -- Sannita (WMF) (talk) 10:42, 21 June 2022 (UTC)[reply]

@Sannita (WMF): I wouldn't want us adding article thumbnails to search results until phab:T306246 is resolved. --Ahecht (TALK
PAGE) 14:18, 21 June 2022 (UTC)[reply]

@Sannita (WMF) Please consider implementing T146418. That was raised in reference to the Special:Contributions, but it applies equally to Special:Search (i.e. the Add namespaces pane). -- RoySmith (talk) 15:00, 21 June 2022 (UTC)[reply]

If you want to improve the search page it would be great if you can fix phab:T215117. 90.227.175.244 (talk) 18:05, 21 June 2022 (UTC)[reply]

Hi 90.227.175.244, I just received a confirmation from the dev team that they will start working on that fix. I cannot promise anything about when the bug will be fixed, but it will be fixed for sure in the coming weeks. Thanks for bringing it up! Sannita (WMF) (talk) 17:20, 29 June 2022 (UTC)[reply]

@Sannita (WMF): Like Ahecht, I'd like to not have thumbnails until phab:T306246 is resolved. Also, I'm not sure if collapsing the advanced search options is a good idea. Instead I think, moving the "sort by" option between the "blue Search button" and "Results 1 – 20 of 859" would be more intuitive for casual readers. All the other proposals look really nice to me. Best. —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:43, 21 June 2022 (UTC)[reply]

@Sannita (WMF): On second thought, casual readers would not care much about when a certain article was created or when it was last edited. Such sorting is useful on e-commerce sites but probably wouldn't be here. So sorting system is probably best placed where it already is. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:45, 22 June 2022 (UTC)[reply]

I don't think that we want all of MediaWiki:Bad image list to be blocked from previews. There is certainly a high degree of overlap, but no reason to block images such as File:Dead rat blood.JPG, File:Encyclopedia Dramatica (logo).png, File:Flag of Hezbollah.svg, File:Osama bin Laden portrait.jpg or File:Swastika.png from previews, just because each of these images is likely to be abused. Animal lover |666| 14:05, 22 June 2022 (UTC)[reply]

@Animal lover 666 It's better than nothing. I'd rather have a few "meh" images not appear than unexpected graphic images showing up in benign search results (for example, a search for "Iran's Penal Code" shouldn't show a thumbnail for Anal sex, and a search for "Canadian Holstein cows" shouldn't show a thumbnail for Anogenital distance). --Ahecht (TALK
PAGE) 14:46, 22 June 2022 (UTC)[reply]

@Ahecht, @RoySmith, @CX Zoom, @Animal lover 666: thank you so much for your interventions and your feedback! I already reported your comments to the dev team.

Regarding T306246, someone is looking currently at the bug. I'll keep an eye on it too, just to be sure that it doesn't get in the way of our development. Regarding T146418, it doesn't apply to our current sprint, but we will take it into consideration for our next steps. I'll keep you posted about it.

Thanks again for your feedback, and if you have more, please keep it coming! :) Sannita (WMF) talk) 12:04, 23 June 2022 (UTC)[reply]

File:Dead rat blood.JPG (don't click if you just had lunch) isn't used in any article here so it won't be affected anyway. If we did have an article for "dead rat" that used it as the first image, I'd argue it shouldn't show up in search results. It wouldn't be appropriate to show to someone who's looking for Deadliest Catch. Wikipedia may be WP:NOTCENSORED, but that's about articles. If you look up shit, you should be served shit. But you wouldn't put "Dead rat blood" on the Main Page, would you? For Osama, I wonder if that image (still) needs to be on the bad image list. File:Flag of Hezbollah.svg is non-free so that's never a page image anyway. File:Swastika.png isn't used in any article, so no page image. Encyclopedia Dramatica is barely legible as a search thumbnail, and again, I wonder if it (still) needs to be on the bad image list. At any rate, it's not a huge loss. Search thumbnails/previews are no necessity, if anything, they are (@Sannita (WMF):) mostly bloat. Having a handful of images that aren't overly shocking excluded is not a big deal. Showing anal sex to kids looking for the home of Disneyland, Anaheim, California, is. — Alexis Jazz (talk or ping me) 14:27, 6 July 2022 (UTC)[reply]

Love all except for 3 and 7 Most of these improvements look fantastic and greatly needed. I would personally oppose removing the outlines for the sister project search, as it makes it less clear and accessible, but I would support changing the color/transparency of the outline and making it rounded. The new position for the new article message also seems a bit wonky, but changing the position in general is fantastic. Thanks for all of your work! 🐶 EpicPupper ^{(he/him | talk)} 16:59, 24 June 2022 (UTC)[reply]

Hi, Sannita (WMF)! My initial reaction before clicking through to all the details: for "Add an article thumbnail to search results", we need T91683 Allow editors control of the page image, which is #8 in this year's Community Wishlist. ⁓ Pelagic ( messages ) 11:10, 6 July 2022 (UTC)[reply]

Hello everyone! Our consultation period about Search improvements will end on July 10, but we already have some initial news that we want to share with you.

Based on your precious feedback that we collected across communities, we decided to take some more time to re-evaluate our proposal on namespace tags, and to tweak slightly article thumbnails in order to make it easier for users to hide them, if needed. We also decided not to proceed with collapsing the advanced search options.

All other improvements received a general positive feedback in the consultation so far, so our plan is to implement them starting from July 11.

There are still some days left for discussion, so you can still help us in refining our proposals. Thanks for your help so far! Sannita (WMF) (talk) 13:25, 6 July 2022 (UTC)[reply]

@Sannita (WMF), looks like I missed the initial window, but having reviewed the changes and the comments above, figured I'd share.

Overall, it looks pretty good, but I agree with others that the concerns about image selection should be resolved.

For namespace tags, many less-experienced editors struggle to understand what they mean, so ideally I'd like to see some sort of explanation of what "user talk" or "draft" means if anyone hovers over the tag on a result.

For other projects, it's important to understand that, although they share the most fundamental core open knowledge mission, beyond that many of them have very different purposes from Wikipedia, which could make some entries there not a very useful result. It's essential that content from outside of Wikipedia be clearly identified as such so that readers know when they're leaving the encyclopedia and going to something else. E.g. if they click a Wikivoyage link expecting it to be basically a Wikipedia article, they'll be surprised when they encounter a statement like "check out this excellent restaurant", which is fine under voy:BEFAIR but would never fly under WP:NEUTRAL.

Moving the “no article found” message to a better position sounds fine from your mockup, but it's definitely important to understand that this message is a key step in the creation of many new articles.

Cheers, {{u|Sdkb}} ^talk 21:45, 15 July 2022 (UTC)[reply]

Hi! I'd like to propose enabling TemplateScripts on the English Wikipedia. It's not a MediaWiki extension, but a few lines of JavaScript added to MediaWiki:Common.js that basically allow to run JavaScript from templates, as long as the code is on the MediaWiki namespace and with the "TemplateScript-" prefix, which requires an authorized user and community consensus to get there.

The system is enabled on the Spanish Wikipedia where it's used for easy signing of polls and projects (see blue button here), for navigating excerpt trees (see box with tree icon here) for injecting interactive widgets on some articles (here and here) and more recently for creating interactive forms that inject content into other pages (see template here, soon to be used on admin boards).

However these are only teasers. It doesn't require much effort to imagine countless other useful applications. So what do you think? Sophivorus (talk) 21:12, 29 June 2022 (UTC)[reply]

Wait wait, is this another one of those "Check every single page load to see if it has text on it, then go load a script" requests? We've shot those down a LOT. — xaosflux ^Talk 23:00, 29 June 2022 (UTC)[reply]

...and yep it appears to be. This should be fixed in core or with an extension, not with this sort of hack. Even an extension was refused by developers (c.f. phab:T8883). It looks like the next possible incarnation is phab:T241524. — xaosflux ^Talk 23:06, 29 June 2022 (UTC)[reply]

This is not a "hack", it's a pretty reasonable implementation. It's also similar to withJS -- with the difference that withJS looks at URL params while this looks at html attributes on the page. The server-side implementation from phab:T241524 has its own limitations – as it requires the script to be a gadget, and EVERY gadget adds javascript to EVERY page load since all gadgets are RL modules that need to be registered by the startup module. That doesn't scale once you have too many gadgets. TL;DR is that putting something in core or an extension isn't a magic solution to performance problems. – SD0001 (talk) 08:46, 3 July 2022 (UTC)[reply]

I would prefer something more focused on improving the encyclopedia. JavaScript is a potential security nightmare and there would need to be a good reason to add more. This tool would appear to give enthusiasts an ability to add animations and games which may or may not be desirable. However, spending time arguing about such animations and games would definitely be undesirable. Johnuniq (talk) 23:19, 29 June 2022 (UTC)[reply]

Well, talking of games, I did wish if there were a quiz thing on Wikipedia. 5 or 10 questions everyday. At the end of quiz you get your score, with short descriptions about all questions asked, nudging them to read the article. If we can run DYK daily, this one shouldn't be hard either, except that I presumed it'll probably require a sitewide javascript to run. I firmly believe that it'll help increase engagement and attract more users. —CX Zoom[he/him] ^{(let's talk • {C•X})} 23:48, 29 June 2022 (UTC)[reply]

@CX Zoom We currently can have most anything where someone "clicks a button" kick off a javascript (either via the old ?withJS handler, or with the new gadget argument) - that's how pages like WP:TWA work. Of course, building and curating constant new quiz data requires volunteers. — xaosflux ^Talk 10:16, 30 June 2022 (UTC)[reply]

@Xaosflux: I did some TWA on my alt account, and its very interesting, except that the blue button at homepage of WP:TWA seems to not be working. Can you please check that? —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:47, 30 June 2022 (UTC)[reply]

It seems to be broken with certain browsers, but no one has volunteered to work on it (one of the systemic problems that would be even worse if we put script-based workflows in front of readers!). — xaosflux ^Talk 14:54, 30 June 2022 (UTC)[reply]

How about 1 question everyday based off WP:DYK. Sungodtemple (talk) 14:07, 30 June 2022 (UTC)[reply]

Isn't 1 a bit too low? I think of starting with 5 per day. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:52, 30 June 2022 (UTC)[reply]

As I discussed at Wikipedia:Village pump (idea lab)/Archive 40 § Proposal 3: Add quizzes throughout the Main page, anyone should feel free to start a quiz (with as many questions as you want a day) to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. Whatamidoing helpfully pointed out that mw:Extension:Quiz exists, though of course that is no guarantee that it would be installed on English Wikipedia. isaacl (talk) 01:07, 1 July 2022 (UTC)[reply]

Thanks, Isaacl. FTR, I requested at testwiki:Talk:Main Page to install the extension so that I can work on it to present a working model. Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:52, 1 July 2022 (UTC)[reply]

As I suggested in that conversation, you can start now with a non-interactive version to establish your daily track record of quiz generation. Good luck! isaacl (talk) 15:25, 1 July 2022 (UTC)[reply]

Hi guys! @Johnuniq Regarding the security risk, isn't it essentially the same as with default gadgets or MediaWiki:Common.js itself? TemplateScripts will just have to go through a similar review process. @Xaosflux Regarding the overhead, it's a single non-blocking JavaScript line run after the page loads (like all code on MediaWiki:Common.js). If the check doesn't pass, nothing else happens. Isn't it a small price to pay for the potential benefits? Of course an extension or core solution would be even better, but it's been 16+ years since that first request and 3+ since the second. We all know WMF times, priorities and capacity. Here we have a chance to open up the JavaScript field on the spot with minimal overhead and security risks that we already know and handle successfully. If it catches on and demand rises, a core solution will surely follow! Sophivorus (talk) 15:25, 30 June 2022 (UTC)[reply]

Sounds like it's worth trying to me. Amongst other things, it would enable the kind of interactive graphics that are used all the time in journalism now, and are slowly breaking into academic publishing (e.g. [2]). Wikipedia is incredibly text-heavy compared to other modern educational resources. This could help us catch up and therefore would definitely be improving the encyclopaedia. – Joe (talk) 15:53, 30 June 2022 (UTC)[reply]

I'm not against this. But its' honestly not something that can't just as well be done right now with a default Gadget, loading other gadgets/pages. And I think that shows this isn't the real problem. TemplateScripts isn't going to increase our high quality JS contributions, because if you were not able to write a gadget to fix your problem before, you won't be able to do so any more with this. The Javascript space is already wide open for anyone who can write high quality code with long term compatibility. But that turns out to be a lot harder than most ppl assume it to be. Specifically, I've seen a big lack of understanding of late loading JS, HTML layouting and styling by most JS authors, which is a hold up for lots of the scripts / gadget proposals that I have seen proposed over the years. —TheDJ (talk • contribs) 09:22, 3 July 2022 (UTC)[reply]

I can't recall the last time a script was held up from being a default gadget due to poor code quality. Rather, the concern has always been "this gadget will cause one line of extra code to run on every page load" which is what this proposal seems to address. – SD0001 (talk) 13:32, 3 July 2022 (UTC)[reply]

Then ppl reviewing the gadgets are not thinking it trough. One liners never matter in the grand scope of things and having 10 of them or 1 of them also doesn't really influence page weight. Page layout stability, printing/text-only compatibility and accessibility however do matter a great deal. —TheDJ (talk • contribs) 08:10, 5 July 2022 (UTC)[reply]

I completely agree, but that's something to bring up with the people who give that rationale. Though I still think a couple of generic lines that can be used by many gadgets is better than 1 line per gadget. – SD0001 (talk) 16:02, 5 July 2022 (UTC)[reply]

Well, with good design, it's possible to create JavaScript-enhanced templates that don't compromise page-layout stability and have reasonable fallbacks for accessibility and printing/text-only mode. However, it's also true that most existing template scripts are meant for namespaces other than the mainspace (all except Vivarium and Formicarium). For example, check out this poll where the script for signing I mentioned earlier is being used intensively and constructively for something that will improve the encyclopedia. All that is to say that I could tweak the TemplateScripts initialization code so that they run only on non-mainspace. If their use and demand grows, we may later re-evaluate if and how to enable them on mainspace (perhaps with adequate design guidelines). Thoughts? Support? Objections? Cheers! Sophivorus (talk) 13:21, 8 July 2022 (UTC)[reply]

Would it make sense to use a "metadata" template to consolidate all the little templates we place at the top/bottom of an article? For example: {{short description}}, {{Use dmy dates}}, {{pp-semi-protected}}, {{hatnote}}, {{Use British English}}, {{Pp-move-indef}}, {{Featured article}}, and so forth. I suppose the advantages would be consistency, simplified maintenance, lower confusion for new editors, and easier management via bots. Praemonitus (talk) 21:40, 10 July 2022 (UTC)[reply]

Not a good idea, imo. This looks like a sink where all kinds of mismatched items are thrown together. I fail to see how this is consistent, easier to maintain, or simpler for new editors. 204.19.162.34 (talk) 22:44, 10 July 2022 (UTC)[reply]

(1) It's consistent because the available options are laid out in the template documentation, rather than relying on tribal knowledge of what templates to add; (2) It's easier to maintain since it is collected together under consistent management; (3) It's simpler for new editors since they don't have to understand a bunch of meta-templates requiring investigating a series of documentation; just the one page. The options can be laid out in a consistent and logical manner. For example, rather than having a slew of {{Use Oxford spelling}}, {{Use American English}}, ... {{Use Sri Lankan English}} templates, you can have a single parameter such as 'spelling_variant='. Praemonitus (talk) 00:11, 11 July 2022 (UTC)[reply]

If you did this, I would leave out the page protection templates -- those are usually placed by admins or bots, and most editors shouldn't be touching them. For the others that seems fine. --Ahecht (TALK
PAGE) 14:08, 11 July 2022 (UTC)[reply]

You can try and create a sandbox version to see if it is viable. I have a feeling you'll get pulled too much into a sink-hole. On the other hand, merging the "Use x language" templates into one template with a parameter name might be something that can work. Gonnym (talk) 14:27, 11 July 2022 (UTC)[reply]

I would support integrating all protection templates into one, but not {{use dmy dates}}, etc. Keeping them at the top of page informs new editors of the correct style to be used. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:22, 11 July 2022 (UTC)[reply]

Protection templates already are integrated into one. Nowadays, they are all wrappers for Module:Protection banner. This works out what the current prot level is for creating, editing, moving, uploading (as appropriate), determines the prot duration, and either displays an applicable icon or puts the page into Category:Wikipedia pages with incorrect protection templates. --Redrose64 🌹 (talk) 20:10, 12 July 2022 (UTC)[reply]

I would like to propose that new articles be created to encapsulate lots of different bus routes.

Background (bus route articles)

On this very wiki, there are a series of articles concerning the various bus routes in London. These articles contain many details about the history of the routes and the vehicles that are used on it. I notice that there is not a lot of this for other Cities and Local Authority areas. This, I want to change, but it require a lot of work and dedication.

My Proposal (bus route articles)

I would therefore like to propose that an assemblage of articles be crated to discuss the bus routes of other major metropolises such as Glasgow and Dublin. I also do hereby request and require that such due process be observed in order to establish a network of pages covering the routes of more rural provinces, such as Ayrshire and the Lake District. I trust that such can be achieve in a timely and competent manner, and so I must propose such action to be conducted henceforth in order to improve the very fabric of this dear wiki.

Considerations (bus route articles)

Before I close, I will lay down a few important points to consider:

1. I notice that there would some issues with establishing notability with some rather more obscure bus routes, but I trust that we can set criteria for that, and I believe that any bus route operating on a 30min frequency or more frequent than that should be fine.
2. Yes, this is a massive project. If we want to cover the routes of all 200 odd countries, then we will be here for a long while. Perhaps we will build out from London first, and work on English routes. Scottish and Welsh would follow, then Northern Ireland and Ireland, and then onto the rest of Europe. If things are going well after this, then work on other continents should proceed in this order: North America, Asia, Africa, South America, Oceania. If at any point, notability is in doubt, then dial back a bit and focus mostly on large cities for a while.
3. Remember, we are trying to eliminate London favouritism here, but we must not go to far and blatantly insult the capital of England. Care must be taken to look after those articles as well, and said articles should be used as a template for new pages.

Conclusion (bus route articles)

I hope this proposal is not too long, both literally and metaphorically. I hope these writings aren’t too long either. I expect good points from both those who support and those who oppose this idea. If there is too much opposition, then it would be good to talk about scaled down versions of this project. Should the need arise, I will create such a thing and post it on this page. Ideas to improve this project are encouraged and will be most useful here. Pablothepenguin (talk) 19:02, 11 July 2022 (UTC) Pablothepenguin (talk) 19:02, 11 July 2022 (UTC)[reply]

@Pablothepenguin Editors in recent times have been highly resistant to creating new subject-specific notability guidelines, so we're left with the general notability guideline. If a bus route meets that standard, it can have an article; you don't have to ask for it here. If it doesn't (as I suspect is the case for most bus routes), it can't. Some of those routes might warrant mention as part of broader-scoped articles on bus routes in an entire city. Check with WikiProject Transport for more info. {{u|Sdkb}} ^talk 21:05, 11 July 2022 (UTC)[reply]

I would imagine that most bus routes are not notable as encyclopedia articles. My town has a bus route that covers a 5 miles (8.0 km) stretch with 4 stops on it - I can't see how the CityName Bus Purple Route is the least bit notable or of interest to anyone not near it. Lists of these may be of some use at wikivoyage, simliar to pages such as voy:en:Ferry_routes_to_Great_Britain. — xaosflux ^Talk 23:04, 11 July 2022 (UTC)[reply]

I could argue the same thing about some of the London routes that are recorded on this very Wiki. Do you see the irony here? Pablothepenguin (talk) 23:48, 11 July 2022 (UTC)[reply]

WP:AFD is right around the corner, — xaosflux ^Talk 00:33, 12 July 2022 (UTC)[reply]

Special:PrefixIndex/Wikipedia:Articles_for_deletion/London_Buses_route has some interesting reading! — xaosflux ^Talk 00:37, 12 July 2022 (UTC)[reply]

Looks like they get deleted and redirected to lists a lot --- then after some time someone just recreates them again! — xaosflux ^Talk 00:40, 12 July 2022 (UTC)[reply]

That being said, pages such as Night buses in London or List_of_bus_routes_in_London themselves don't seem t as useless. — xaosflux ^Talk 00:43, 12 July 2022 (UTC)[reply]

I am prepared to create more AFDs for these pages if my proposal doesn’t work out. I may have to “ruin” them to get them deleted as well. If you don’t know what I mean, I’m talking about messing with them to make them severely shoddy, then immediately submitting the deletion requests. Pablothepenguin (talk) 00:51, 12 July 2022 (UTC)[reply]

I would advise you to read Wikipedia:Do not disrupt Wikipedia to illustrate a point before attempting anything like that. - Donald Albury 01:23, 12 July 2022 (UTC)[reply]

Perhaps don't do that... Anarchyte (talk) 11:34, 12 July 2022 (UTC)[reply]

I think a general problem with bus routes is that they can easily be changed by the bus authority since they don't rely on any fixed infrastructure short of terminals. A route that has run for a long time may be notable per GNG but I can't expect every route in a metro area to be that way, even London. --Masem (t) 11:42, 12 July 2022 (UTC)[reply]

• I would think that the more useful approach would be to have an article on the town’s bus system (as a whole)… that article would contain an external link to the website of that system (which, presumably, would cover the individual routes). That way Wikipedia can point readers to the information they desire, without having to worry about updating our article every time a specific route changes. Blueboar (talk) 13:12, 12 July 2022 (UTC)[reply]
• A few bus routes are individually notable, but they are rare. Most bus routes are better covered in articles about the area(s) they operate in, bus routes of [place] and/or transportation in [place]. For public transport articles generally, it is almost always going to be significantly preferable to write articles in a top down order, starting with articles about transport in <country/state/region>, then transport in <city>, then list of bus routes in <city>, and only writing the <City> bus route n article once all the higher level ones are at the very least start class (with C or better being preferable). Even then I recommend not publishing an article about an individual bus route unless it it is fully sourced and very clearly meets the GNG otherwise someone will nominate it for deletion. Thryduulf (talk) 13:35, 12 July 2022 (UTC)[reply]

• There's both the main implicit question and a different question if taken literally. The main implicit question is avoiding separate articles on bus routes, usually by folding them into a higher level article. I'd say follow the rules, and GNG will almost always exclude these. They are usually ethereal / abstract short-lived entities that exist only in the schedules of the organization that runs the buses. The exceptions to this will pass GNG. The ostensible/ literal question (creation of higher level articles) sounds like a good idea but is probably not the actual question.North8000 (talk) 13:57, 12 July 2022 (UTC)[reply]

  They are usually ethereal / abstract short-lived entities that exist only in the schedules of the organization that runs the buses while there are unquestionably many bus routes this accurately describes, there are very long lasting routes (e.g. route 126 between Wells and Weston-super-Mare has been operating the same route with only minor alterations since at least 1967) that are not ephemeral and have some an existence outside timetable pamphlets (e.g. they appear in tourist guides, nostalgia discussions, etc.) but which do not meet the GNG (most of the info about the 126 route is on pages whose primary subject is the vehicles that have been used on it). These shouldn't have standalone articles, but they do merit mention somewhere. Thryduulf (talk) 15:54, 12 July 2022 (UTC)[reply]

I am thinking through the possibility of setting up RFDs for the London bus routes. I am aware of the need to combat London favouritism at this point in time. I have noticed that things that happen in London or things that are commonly associated with London, such as London buses, are automatically several hundred times more famous and noteworthy than things that happen in my neck of the woods. My two nearest cities, Glasgow and Edinburgh contain quite wonder things. But said things will never received the attention and interest that London things get. I am outraged at this decadence, and do anything to try and remove it. It is difficult work, as I do not want to offend Londoners, and I also do not wish to cause mass confusion.

Over the years, I have read many detailed histories of UK buses, each of which has contained very detailed information about the UK bus network. The one thing that has always annoys me in this case is the fact that said histories devote up to half of their time talking about just London. An example of this is that they will typically discuss how the first London buses, which were pulled by horses, plied their trade in the Victorian era. They will then go on to say that London made the decision to upgrade to motor buses in the early 1900s. The entire histories are full of stuff like this. Have they forgotten that every city in the UK made the same transitions? Are they not aware of beautiful companies such as Lothian of Edinburgh, and the main provider of buses in Birmingham? In addition to this, London vehicles, such as Routemasters, get a lot more attention that other buses, such as the Alexander and Albion vehicles that operated in the central belt of Scotland.

London buses have always confused me. Their refusal to accept the factual truth that LED destination displays are just plain better, and their insistence on obliterating First Bus purple, and Stagecoach White in favour of a boring Red livery (I prefer Stagecoach-type liveries with swirls and stripes to solid colours), confuse me to this day. Do remember, this is a company so backward, that their last conductors went in 2005 (Most places stopped this in the 1980s), and they still use roller blinds to display route info, even though my local buses stopped doing this in the 1990s.

But those London folks reel me right back in, with their more detailed route information, and their stop announcement systems. They also had a massive electric and hybrid bus fleet before anyone up in Scotland got there. Plus they also have separate doors for entering and exiting the bus. That’s why I strongly dislike them, because they confuse me by being backward and forward thinking simultaneously. I do not understand them at all, and I think you would need an IQ of at least 300 to truly figure them out.

Anyway, I should wrap up now. I believe London should switch to LED and throw out the roller blinds. Also, they should allow multi-coloured liveries with swirls and custom logos. Red is the colour of anger, evil, greed, and the Devil; London should move away from this. I recommend Green, the colour of environmentalism and nature, or blue, the colour of calmness and the Sea. There is also White, which represents peace and sterility, and Gold, which stands for wealth and prosperity. For the sake of tradition, heritage buses should continue to be in red, along with one or two independent London bus companies. My bus companies, as well as other Scottish firms should take notes from London’s positive strategies, such as stop announcements and bigger Electric fleets. Scottish buses should also be fitted with more detailed route information, as in London, where many via points are displayed as well as the destination. Pablothepenguin (talk) 17:30, 12 July 2022 (UTC)[reply]

In addition to the links you were given to read earlier, please also read Wikipedia:Right great wrongs before taking any action at all like you've just proposed. Thryduulf (talk) 19:16, 12 July 2022 (UTC)[reply]

I will be careful. Pablothepenguin (talk) 19:21, 12 July 2022 (UTC)[reply]

If you, or someone (unlikely) could write a raft of articles like this historical one, a journey from one end to the other that I had to make over 100 times as a child and in the 1950s from my home town, then parts of your proposal might have potential. But although it was a stable route for decades from 1913 to 1976, it now changes its route every time I use it on my free bus pass. However, the 144 is one of only 42 routes to have made its way to Category:Bus routes in England, and nowadays bus routes are so volatile that such articles would need a permanent team to keep them updated. That said, I fear much of your longer post above appears to be somewhat off-topic. Kudpung กุดผึ้ง (talk) 22:35, 12 July 2022 (UTC)[reply]

The Foundation has changed jawiki's default skin to Vector (2022).
Discussions on jawiki about this matter have been confusing.
In addition, since the change was made suddenly and without notice to the general public, there is widespread confusion in the Japanese social networking community about the change.
The Foundation will try to make changes to enwiki next.(https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements)
Would the English-speaking community agree with this?
If you English speakers think this is OK, then forget about this topic, because the Japanese and English speaking communities have different ideas about site design.
If not, once changes are made, it will be very difficult to revert.
Please ask the communities you know, such as Facebook, Twitter, WhatsApp, and Discord, whether they agree or disagree with the Vector (2022) specification.
Then, invite everyone on each social network to participate in the discussion.
Whatever the outcome, we believe it will lead enwiki in a better direction.

(Original text)
jawikiの前例から考えるVector (2022)のデフォルトスキン化の懸念について
財団はjawikiのデフォルトスキンをVector (2022)を変更しました。
この件についてjawikiでは議論が紛糾しています。
また、一般ユーザーへの告知がなく、突然行われたため、日本のSNSコミュニティでも変更への混乱が広がっています。
財団は次にenwikiに変更を加えようとするでしょう。(https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/ja)
このことについて英語圏の皆様は賛成でしょうか？
日本語圏と英語圏ではサイトデザインへの考え方が異なるので、英語圏の皆様が問題ないと考えるのであれば、このトピックは忘れて下さい。
そうでないのであれば、一度変更が加えられたら戻すのは大変です。
Facebook、Twitter、WhatsApp、及びDiscord等あなたの知る限りのコミュニティでVector (2022)の仕様について賛否を問うて下さい。
そして、各SNSの皆様に議論への参加を呼び掛けて下さい。
結果がどうであれ、そのことがenwikiをより良い方向へ導くと信じます。 HarukaFujihira (talk) 21:01, 12 July 2022 (UTC)[reply]

• Why would we ask social media? Schierbecker (talk) 01:21, 13 July 2022 (UTC)[reply]

  Many Wikipedia users are IP users who do not have a registered Wikipedia account and use Wikipedia by searching from the Wikipedia main page, searching from Google, or accessing via hyperlinks from social networking sites. IP users are not informed that the default skin will be Vector (2022).
  

  If many users including IP users agree to Vector (2022) after the default skin is changed to Vector (2022), there will be no problem. However, as we can see from the examples of Japan and France, a lot of protests and confusion are expected.
  

  I have proposed a method to inform IP users in advance through social networking services as a way to prevent confusion in advance.
  

  If the consensus of enwiki users is that there is a better solution than SNS, or that there is no need to prevent confusion, then please ignore this topic. I am not forcing people to use SNS to spread the word. HarukaFujihira (talk) 02:44, 13 July 2022 (UTC)[reply]

Plagiarism bot: One of our scripters could create a bot that would run checks to see if a large portion of the text was copied from another Wikipedia article, and flag it. divisionsign ^{speak of the devil} 23:05, 12 July 2022 (UTC)[reply]

seems pretty useless, we already have earwig but this is a matter of attribution and not that big of a problem. PRAXIDICAE🌈 23:06, 12 July 2022 (UTC)[reply]

If it's "on-demand" like the side-bar citation bot, I don't see how this would be an improvement in lieu of Earwig. —VersaceSpace 🌃 23:24, 12 July 2022 (UTC)[reply]

There is a bot that will flag copyvio, at least in draft space. I forgot the name of the bot, but it flagged a draft I was working on when I included a quote in a cite. This is where I removed the quote based on the bot flagging. Unfortunately I can't remember the bot name, or find the flagging in any log. ScottishFinnishRadish (talk) 23:32, 12 July 2022 (UTC)[reply]

It's EranBot. Many of its reports involve unattributed copying within Wikipedia, and those can be fixed by whomever is dealing with the report at CopyPatrol. DanCherek (talk) 23:46, 12 July 2022 (UTC)[reply]

I would be concerned that such a bot could have chilling effects on use of quotations which are used correctly—it would probably be very hard for an algorithm to distinguish between proper and excessive direct quotations, and I don’t want editors to be derailed by false positives. Yitz (talk) 03:22, 17 July 2022 (UTC)[reply]

Hi everyone,

We would love to see the Vector 2022 skin (see what it looks like) become the new default across all wikis, including English Wikipedia. The skin would be turned on for all anonymous users, and also all logged-in users who now use Vector (the current default). Logged-in users are and will be able to switch to any of our other available skins, including the current Vector. We will be ready to begin making the change at the end of August (and not in July, as previously announced), when the visual refinements and other deployment blockers are ready.

The goal of the project is to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use page and user tools, and more. The team has been working on this change for the past 3 years, ensuring that every change is thoroughly tested and proven to work.

Making this change is important for both readers and contributors.

We need your help and feedback on how to proceed. We have two requests:

1. We need to talk in a way that works well for the English Wikipedia community. What would be the best format and timeline to discuss the change? We have included a proposed format below, and are interested in what you think about it. If you agree, we can begin the deployment conversation in one week. Here is our suggestion:
   1. Have the deployment conversation that would take 2 weeks. The goal for that discussion will be to identify breaking issues or opportunities for improvement for the new skin. It will be important for us to reduce the risk of bugs or imperfections that would be particularly troublesome on English Wikipedia
   2. After the deployment conversation, we get back to you with a prioritized list of remaining work/fixes necessary prior to deployment
   3. Before the deployment,
      1. Banners announcing the change will be displayed for logged-out and logged-in users
      2. The announcement will be made both on the Village Pump as well as in the Tech News.
   4. We proceed with deployment once the agreed upon fixes are ready.
2. We need to understand the perspectives of different parts of the English Wikipedia community. What forms of communication would help to gather feedback and further raise awareness for the English Wikipedia community? We would like to have an open discussion, but are open to other forms such as requests for comments, office hours dedicated specifically for the English Wikipedia community, or guest presentations at community meetings. If necessary, we can also adjust the timeline of conversations based on your needs.

We welcome your replies here, or via email (olga@wikimedia.org, sgrabarczuk@wikimedia.org), as well as during our next office hours (26 July).

Thank you for your time and help. OVasileva (WMF), SGrabarczuk (WMF) (talk) 12:05, 13 July 2022 (UTC)[reply]

The comments from jawp above suggest that this change may not be entirely uncontroversial, with some editors feeling that it is not an improvement. Will enwp be allowed any say in whether the change is rolled out at all, or is it being imposed with our only input being into the details? Certes (talk) 12:48, 13 July 2022 (UTC)[reply]

No matter what change, there is a guarantee that a certain amount of people will not feel like it is an improvement. That in itself is a very bad metric for decision making. Are the points being made valid, is there an opt out, what other problems are we solving and are the people responding an accurate representation of the larger group of users. Those seem like much more critical questions to me. —TheDJ (talk • contribs) 13:08, 13 July 2022 (UTC)[reply]

I didn’t like it at all when I tried it, but I’ve been won over after spending some time with it. Doug Weller talk 13:14, 13 July 2022 (UTC)[reply]

Is there a list of blockers that are being accepted as blocking tasks right now?

• I think the table of contents handling parts are the biggest problem right now. We currently have a lot of control over the TOC placement and display, which seems much harder or impossible with vector-2022.
• Personally, I think with our "wide vector-2022" gadget option being an option for editors, general editors may be OK -- if we can ever get control over what is going on with the left sidebar - it comes, it goes, it is hard to control.

— xaosflux ^Talk 13:08, 13 July 2022 (UTC)[reply]

Here are 2 examples of the sidebar with the wide gadget: an article that doesn't for a TOC, and article that has a displayed TOC. In the later, the entire sidebar will collapse, but only at certain display sizes, there is a task out there about being able to collapse the TOC - but very notably, even when collapsed that sidebar stays open an empty. Is the "grid" work going to address that at all? The sidebar element seems to be part of the content container. — xaosflux ^Talk 13:11, 13 July 2022 (UTC)[reply]

I quite like the wide-vector-2022 layout and I'm sure I could be won over after a few weeks of it being the default. I think I'm in the minority when I say I like the ToC positioning on the left (but only on wide-vector). I strongly dislike the normal (non wide) version of Vector 2022, and I've left comments here on why this is. As for the OP's question: I don't think enwp will take kindly to a discussion about setting Vector as the default while these issues of narrowness, ToC placement, and unnecessary top banner whitespace exist. Anarchyte (talk) 13:31, 13 July 2022 (UTC)[reply]

I don't hate the side-bar based TOC in vector-2022 (even with wide mode) - I mostly hate that when all the sidebar elements (toolbar, and hopefully soon to be TOC) are collapsed or docked, that the sidebar can't be collapsed without also adding in javascript hacks - I'd think this should be possible with css and a layout that allows it to widen if there are contained elements pushing the margin. — xaosflux ^Talk 13:38, 13 July 2022 (UTC)[reply]

Hiding the TOC and then regenerating a custom TOC (as in this article does achieve what I'm looking for I suppose - not sure why that is so hard? — xaosflux ^Talk 13:42, 13 July 2022 (UTC)[reply]

Perhaps something the team could look into could be having the __TOC__ magic word forcing the TOC to exist within the page instead of in the sidebar. Anarchyte (talk) 14:38, 13 July 2022 (UTC)[reply]

Hey @Xaosflux - thanks for the feedback, and quick answer to the sidebar question (I'll follow up on your other points around magic words a bit later). Once the new ToC collapsing behavior is ready (phab:T306660), the gadget should work again to stretch the full width if both the sidebar and the ToC are collapsed OVasileva (WMF) (talk) 13:37, 15 July 2022 (UTC)[reply]

@OVasileva (WMF) thanks, looking forward to trying that out - I think it will at least alleviate some worry for logged-in-editors that have concerns about "too narrow" - likely some of the more heavy power editors that are using wide desktop monitors, I don't think it is a big deal for casual readers. From initial notes below, seems like the loosing control of Table of Contents styling in general is at least an emerging concern among editors - I'd hate to see ugly hacks get pushed by the community if there is an impasse (like the continuing problems going on in Wikipedia:Village_pump_(proposals)#RfC:_Showing_Editnotices_to_mobile_editors below with Mobile Front End and developers preventing certain elements from being controllable). — xaosflux ^Talk 13:52, 15 July 2022 (UTC)[reply]

• Regarding TOC handling in general, for example in these articles editors have specified a custom right-sided TOC, which vector-2022 overrides. — xaosflux ^Talk 13:34, 13 July 2022 (UTC)[reply]

  It seems quite inconsistent though, see this article in vector where editors have determined the best TOC layout type, compared to it vector-2022. — xaosflux ^Talk 13:46, 13 July 2022 (UTC)[reply]

  I think the primary reason we have customized TOCs is when they are very long. Of the most common variants, the floating variants ({{toc left}}, {{toc right}}), {{toc limit}}, and {{horizontal toc}} all exist to deal with a long table of contents. General point: except for people who customize their skin selection away from Vector22, I don't think we need to support these at all in the new skin. We can leave the templates alone right now for those people who do use the other skins, if we want. Specific points:

  1. Floating variants: simply don't care
  2. Toc limit: With a per-level collapsible table, totally obsolete.
  3. Horizontal toc: Maybe the only interesting one, since its major use cases are 'letter/number-driven' lists and large categories, and I expect that a TOC that long will be rough on the sidebar version (I haven't checked yet). I think there's probably a feasible feature request somewhere regarding category tables of contents.

  I think forcing the TOC to appear in page besides maybe that last one isn't needed at all (and I don't think that needs anything more than the customization we can already build with a template). Izno (talk) 19:59, 13 July 2022 (UTC)[reply]

phab:T306246 was mentioned above in #Consultation on Search improvements by CX Zoom and Ahecht and myself. That must be solved, and not by updating documentation, declaring it not a bug or closing it as a duplicate of $random other task. (I occasionally see tasks getting closed without a real solution so I'm just saying) I see plenty of open tasks on phab:T309972 so there's plenty to do. From a UI perspective, I suggested some improvements on phab:T302641, that alone is a hard deal breaker to switch for me personally. — Alexis Jazz (talk or ping me) 20:31, 15 July 2022 (UTC)[reply]

SGrabarczuk (WMF), if you choose to make this change, it will be important to the success of the change to have a team of developers available to monitor forums where bugs and feature requests are reported, create phab tickets actively, and resolve those tickets quickly. Too often, new features are rolled out in beta form (I'm thinking especially of the Visual Editor) and then the development team appears to move on to new projects, leading to bug reports that linger for years (I'm thinking especially of the Visual Editor). I encourage you to designate a place local to en.WP, de.WP, Commons, and other large MediaWiki installations, where editors can report problems without having to travel to unfamiliar sites with different interfaces and watchlists, like mediawiki.org. – Jonesey95 (talk) 14:38, 13 July 2022 (UTC)[reply]

Hi @Jonesey95. Oh, that's a very fair comment. I'm giving a bunch of quick replies to different parts of your comment. I hope these bits make sense together:

1. VE was launched, correct me if I'm wrong, like... 9 years ago? we've learned a lot since that. For example, earlier this year, when planning the current Californian fiscal year, we decided that we would dedicate some time this summer and fall (the first months of the fiscal year) just to further improve Desktop Improvements if needed. So that part's safe, not only in our hearts, but on the governance level, too.
2. As a result, some bugs and feature requests will definitely be handled. Depending on how much related to Desktop Improvements, these will either be just done or considered as part of future projects.
3. Vector 2022 is the default on ~30 wikis. On a few of these, incl. French Wikipedia, it has been the default for almost two years! So they've done a great deal of bug-reporting/feature-requesting already. I think both our team and other communities may be truly grateful for that.

SGrabarczuk (WMF) (talk) 15:04, 13 July 2022 (UTC)[reply]

Thanks. I wish you luck. If all goes well with desktop improvements and the developers find that the set-aside time is available for other work, maybe some of the team can work on the VE backlog and officially get it out of beta status. A bunch of us gnomes who clean up errors that it generates would be very grateful. – Jonesey95 (talk) 15:52, 13 July 2022 (UTC)[reply]

?? "Vector 2022" has been the default on frwiki since 2020? Does it have time traveling properties? — xaosflux ^Talk 18:22, 13 July 2022 (UTC)[reply]

@Xaosflux, you are kidding, right? Let's make it clear for everyone around: back then, it wasn't labelled as "Vector 2022", but it was there. We've been adding more and more features and changes, but the first ones (different logo, collapsible sidebar, limited width) have been the default on some wikis since July 2020. SGrabarczuk (WMF) (talk) 19:11, 13 July 2022 (UTC)[reply]

@SGrabarczuk (WMF) Yes, that was mostly humorous, just contrasting that the entire current incarnation it hasn't had 2 years of bake-in. — xaosflux ^Talk 19:17, 13 July 2022 (UTC)[reply]

Yeah, right. It's a good opportunity to make it clear that this interface isn't static, really. These incarnations are like ogres - both have layers. Some are two years old, and some (like the sticky ToC) are two months old. The older a layer is, the more people have actually used it, noticed bugs, advocated for improvements, everything. It's not like we're pulling Vector 2022 with everything about it out of a hat. I hope it's reassuring. SGrabarczuk (WMF) (talk) 19:29, 13 July 2022 (UTC)[reply]

Jonesey95, to sober up here's Growth-Team's profile on Phabricator. Two projects in active development, one project with a new owner and 11 projects with "passive maintenance" (read: unless the building is on fire expect nothing) with the note "New owner needed". Probably just some obscure projects, right? Yeah, it's just WP:WikiLove, WP:Echo, WP:Thanks, WP:Nuke, WP:Page Curation, Special:RecentChanges. Not anything people really use, you know. — Alexis Jazz (talk or ping me) 21:03, 15 July 2022 (UTC)[reply]

I suggest having a page somewhere that essentially functions as a press release and/or a list of FAQs. At the miminum, link this page in the banners (i.e. with a CTA: 'Read more about the upcoming change!') so that 1. non-registered visitors can read more about the impending changes (and possibly encourage them to register as editor even if it is just to revert back to the previous skin); 2. interested publications may organically pick it up as a story for their audience. – robertsky (talk) 18:08, 13 July 2022 (UTC)[reply]

Great idea, @Robertsky! We're working on a page on wikimediafoundation.org (for readers, media, the "general public"), and we'll definitely have a more detailed FAQ for editors. SGrabarczuk (WMF) (talk) 18:18, 13 July 2022 (UTC)[reply]

I'd recommend that said press release/FAQ page should also include instructions on how to revert back to the older vector skin. I imagine that there will be a fair few (including myself) using the current vector who would like revert back to the older form, and while I know how to switch skins, there are some who may not be familiar. Hog Farm _Talk 19:58, 13 July 2022 (UTC)[reply]

For this change to be a success you can't just impose this on enwiki; you need consensus from the community. Are you willing to open an RfC that seeks to obtain consensus to implement this change? BilledMammal (talk) 21:25, 13 July 2022 (UTC)[reply]

@BilledMammal, I think the proposal pretty much answers your question. Let me rephrase a part of the first message: in the next conversation, we'd like to talk what remains to be done instead of having a yes/no situation. And we do mention RfC there, too. SGrabarczuk (WMF) (talk) 22:36, 13 July 2022 (UTC)[reply]

Your comment comes across as if this is a done deal, with only small details (what remains to be done) to be worked out, but the community needs to be able to reject this. It needs to be able to say that it is not satisfied with the current version of Vector 2022, and instead ask you to come back and see if consensus has changed when you believe you have addressed the objections raised in the discussion.

To rephrase my question; are you willing to open an RfC that seeks to obtain consensus to implement this change, with an option that will permit the community to reject the change? BilledMammal (talk) 22:53, 13 July 2022 (UTC)[reply]

+1 to User:BilledMammal's comment. In that vein: Consider me an Oppose to switching the default. On my screen at least, V2022 has a very poor layout that looks unclean and would create a poor impression of Wikipedia, forced upon us by the WMF. I want to see a finished product before everyone without an account (that is the majority of users) are suddenly switched to a new (worse) look. Happy Editing--IAmChaos 21:44, 13 July 2022 (UTC) edited 01:50, 14 July 2022 (UTC)[reply]

We believe this change is extremely important for readers, and have a lot of data and research that can help us prove this.  That said, we understand that that community might need more from the skin than what is currently developed. That’s why we hope to get into the details so we can identify what needs to be changed before the conversation on whether and when that change will happen begins. That said, to be clear, we will not be rolling out the new skin prior to coming to such an agreement with the community. SGrabarczuk (WMF) (talk) 16:46, 15 July 2022 (UTC)[reply]

@SGrabarczuk (WMF): Thank you, I am glad to hear that. Are you able to provide us with the data and research reports so that we can consider this change in that context? BilledMammal (talk) 22:35, 16 July 2022 (UTC)[reply]

@BilledMammal see § UX research and usability testing below. There's a great deal available there and at other pages, so please specify what else you're seeking if you'd like additional research. {{u|Sdkb}} ^talk 22:40, 16 July 2022 (UTC)[reply]

Thank you, I missed that. BilledMammal (talk) 02:13, 17 July 2022 (UTC)[reply]

@IAmChaos Olga and Szymon explicitly structured this conversation as a meta-conversation about process, not a !vote on implementation. Let's respect that by avoiding bolded !votes, just as we do at VPI. {{u|Sdkb}} ^talk 23:02, 13 July 2022 (UTC)[reply]

I appreciate that. I will unbold. Happy Editing--IAmChaos 01:50, 14 July 2022 (UTC)[reply]

I think just waiting until the "final" release version is ready and usable before starting any discussions on adding it is best. While prototypes are still ongoing it isn't great to start any discussion on a non "final" version when signficant changes can still occur and the outcomes on changes are not released. Using the latest prototypes: Color schemes, borders, toc highlighting & logo choices should be able to be viewed at the point the discussion starts rather than lumped in at the end and not allowing anyone to voice their opinions on these choices specifically isn't a good idea. Terasail^[✉️] 22:02, 13 July 2022 (UTC)[reply]

@IAmChaos, @Terasail, we're not there yet. Please take a look at the proposal. You'll find the replies there. We don't have a definition of a "good enough" product. (In a way, it will never be quite "finished", just as most Wikipedia articles never are.) We'd like to make it together with the community, and now, we're asking how do you think we should do that. SGrabarczuk (WMF) (talk) 22:34, 13 July 2022 (UTC)[reply]

It sounds like this product, if approved, will see regular releases. Will these releases also be discussed with the community or will they be boldly implemented? BilledMammal (talk) 22:58, 13 July 2022 (UTC)[reply]

@BilledMammal, I'm not sure I understand your question. What do you mean? Could you elaborate on that? SGrabarczuk (WMF) (talk) 23:26, 13 July 2022 (UTC)[reply]

@SGrabarczuk (WMF): If I have understood you correctly this version of Vector 2022 is not the final version; instead, it will see regular significant updates. My question is what your process for implementing these updates will be; will you do them boldly or will you discuss them with the community first?

In some ways, this question is related to my question above from 22:53, 13 July 2022, which I believe you may have missed. BilledMammal (talk) 00:58, 14 July 2022 (UTC)[reply]

Thanks for clarifying your question! What we mean when we say that this is not the final version is:

• We still have some identified issues (documented as tasks) that are not resolved. This is the list that is under this task.
• The two-week conversation we're proposing would be meant to help us define the version upon deployment. We need agreement between our team, the needs of readers, and the community in the identification of what their needs from the skin are. What are the blockers to changing the default? That is the conversation we are currently trying to set up.
• Once deployed, we plan on continuing to work on the desktop experience. Our next focus will be on improving some of the features we’ve built here, but also using some of the things within the new interface to begin exploring goals that are even further-reaching, such as encouraging more interested readers to begin editing.  With Vector on most Wikipedias, we didn’t change the skin for 12 years. This project, while improving usability for existing tools, did not add or remove any current tools from the interface. Once it’s done, it gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is a process that is ongoing and will be done with the feedback and collaboration of the community here and across other projects.

SGrabarczuk (WMF) (talk) 17:18, 15 July 2022 (UTC)[reply]

Thank you for clarifying this as well. I am glad to hear that you will seek input and hopefully consensus from the community before implementing any significant updates. BilledMammal (talk) 22:35, 16 July 2022 (UTC)[reply]

@SGrabarczuk (WMF) Firstly, thanks for your reply, I appreciate you being willing to answer so please don't feel like I'm jumping on you specifically, its just that you brought this here and I figured I should voice my concerns with a switch to V22. @Sdkb replied to my earlier comment, and I agreed so I modified it with their suggestion. I strongly believe though, even in this so called "meta" conversation about process, we shouldn't be ignoring the issues. Logged out editors are the most populous user, even though they have practically no voice in ProjectSpace discussions. If we are to implement a change to what they see (ie default settings), we need to address this more than other things, because those affected won't discuss it. Here's a quick list of what I've found.

1. The TOC issues. They are being overriden against specific decisions by editors who chose to design a page a certain way. for example, see Alien, which is the first page alphabetically that uses {{TOC right}}, why should V22 override, there is no precedence in monobook, timeless, minerva which are the other skins installed on enwiki. I think overrides like that (and there may be others, this is just what I have seen conversation about above) should fall to editors, not to software.
2. The look of it. Not to be mean to the team who worked very hard on it, and I appreciate what you've done for the MediaWiki community, but I feel that there are (in the current state) some things objectively worse. Why is there just blank space to the right of articles when V(legacy) reaches the edge of my screen? Why is there space blank to the left of the sidebar that is just white? The sidebar is highlighted in gray which only makes the large blank more obvious.
3. In a similar vein to the blank space - the bar across the top is unbalanced - The user icon is all the way to the right over the blank space, but the arrow on the left is indented like the sidebar, it looks unbalanced.
4. This one is a much more niche issue - and probably one that you will never work on (and don't need to at least for enwiki), but for a user such as myself who has a long sidebar - multiple scripts add links to mine, the TOC is impossible to find for multiple sections - for example on Butetown - I have scrolled down to section 4 (#Welsh language) before the TOC is caught up with me. This may be a concern though for other projects that have added links to their sidebar, such as my private mediawiki site, which has many sidebar links for my convenience.

On the note that I have now spoken about your hard work in a less than stellar light, I again apologize if I came across as harsh, but these are things that I feel need to be addressed before such a big switch for such a prominent website in today's world. Again, I don't want to come across as rude, but I feel we shouldn't rush into this, and that as sdkb called it, the 'meta-process' should include the community's voice on the actual skin itself, and how it could work for enwiki, instead of just how it will be rolled out. (full disclosure: I havent looked at the deployment blockers you linked, because that's a long phab list, and I still don't quite understand all the lines on it, but I will and am open to the possibility that there are other concerns that are more pressing or maybe I'm a complete minority opinion.) Happy Editing--IAmChaos 02:20, 14 July 2022 (UTC)[reply]

I find myself agreeing with you here, particularly on aesthetic grounds, where it looks almost amateurish to me. I have not yet had the time to introspect on why I’m receiving that impression (perhaps I’ll update this later though), so take my take with a grain of salt. I definitely think it’s important not to rush this, considering the extreme outsized effect UX design seems to have on people. Yitz (talk) 03:29, 17 July 2022 (UTC)[reply]

A request for comment is an open discussion. It's just an open discussion that is geared towards assessing consensus rather than discussing something in the abstract, or as in this topic, having a discussion where you create a plan. So a request for comment, which often runs for 30 days but can go shorter if consensus is clear or longer if discussion remains active, advertised on WP:CENT feels like the right way of having this open discussion with the enwiki community. Best, Barkeep49 (talk) 01:34, 14 July 2022 (UTC)[reply]

One extra thought. If there's a sense that consensus might be initially hard but there's a courage of conviction that the skin will genuinely help, some sort of testing, whether through a trial period (owing to enwiki's massive reach lots of data can be collected in shorts period of time), or through A/B testing, with clearly defined metrics could lead to a consensus that wouldn't be there without that data. This is something the Growth Team has done to large success. Best, Barkeep49 (talk) 01:39, 14 July 2022 (UTC)[reply]

I like a lot of what Skdb has said below, particularily that it will be an uphill battle for it to gain acceptance. Another factor is that the enwiki users being asked what they think about the change would generally be the heaviest users; casual readers won't see any future RfC's. These users are probably most accustomed to Wikipedia's current look and would most likely be relatively quick to oppose in my opinion. I also think that starting an RfC about 'Should Vector 2022 become the default after it is modified' (so that the RfCs aren't forcing the community to do things and don't have that appearance, also forestalling complete skin opposition in other RfCs) and then following up with one about 'what should those modifications be' could be a good idea. That assumes the community would reject the skin in its current form. —Danre98^{(talk^contribs)} 00:05, 15 July 2022 (UTC)[reply]

I would second both thoughts by Barkeep. Specifically, (1) a full 30-day policy RfC, listed on CENT and following the requirements of WP:PROPOSAL, is the gold standard and the only realistic path to legitimacy for such a large change. (2) The change is much more likely to gain consensus with solid supporting data from A/B testing. Best, KevinL (aka L235 · t · c) 00:39, 15 July 2022 (UTC)[reply]

FWIW, I am a moderate user (just under 10 edits per day average over the past year, but with over 5,000 pages on my watchlist). After using Monobook for many years, I switched to Vector 2022 a few months ago. It felt a bit wierd at first, but I am now quite comfortable with it. Of course, you are much more likely to hear from users that don't like it than from the rest of the spectrum of user reactions. - Donald Albury 15:56, 15 July 2022 (UTC)[reply]

Agreed. Doug Weller talk 17:24, 15 July 2022 (UTC)[reply]

Re BilledMammal, Barkeep49, IAmChaos, Sdkb comments on this page about consensus...YES. Changing the editing experience by default for Vector 2010 users without an Opt in....not my favorite and would probably guarantee a strong blowback. Changing the editing experience around here is always fraught with challenges and difficulties (Yeah, VisualEditor...), the chief among them, for me at least, is that I am an editor. I am not someone who approached Wikipedia editing from a developer/programmer/coding/data point of view, I'm just an editing/researching/writing fool and I think there are many of my kind amongst named Wikipedia accounts. I just stumbled upon this discussion by accident and probably wouldn't have known that a change was coming/had been instituted until it happened...
And a plea for the future... If the Vector 2022 skin comes online can we please have clear/easy-to-understand Opt-Out instructions? Maybe have them come up for six months afterwards for Vector 2010? Maybe have an Easy-to-find/Clearly-labeled FAQ for the changes and for Opting-Out? When the "Section edit/Reply to individual posts" change came online recently (I'm sorry but I can't quite remember what the name actually is/was) it was Not Easy to find how to disable/Opt-out from the change. Heh, at least it was not easy for me and I have over 35K posts... That's about all, I'll try to keep up and follow this discussion so it won't be another Big Surprise to me. Shearonink (talk) 17:01, 15 July 2022 (UTC)[reply]

Hey @Shearonink, first of all, I understand you. I became a Wikipedian years before I was hired by the Foundation. I personally, as well as other staffers at the Foundation, know that there are thousands of people not editing every day, not engaging in the Village Pump discussions, and finding it difficult to adjust to technical changes impacting the editing experience. So the link to opt-out is and will be available in the Vector 2022 version of the sidebar (left menu). As we wrote, we are also thinking about putting up banners before the launch. SGrabarczuk (WMF) (talk) 17:46, 15 July 2022 (UTC)[reply]

It is unfortunate that the en.wiki editor community has been determined through all obstacle to keep this embarrassment of a UI stuck in the year 2001. Despite many excellent proposals for reform of the Main Page, it remains a dull and outmoded layout; the left sidebar is cluttered and unusable by all who have not become accustomed through years of use to its contradictions. Here we have a vector that is far more modern, far more intuitive and far more pleasant for readers—the only problem is that editors who have been here for many years can't possibly approve of it because they've optimised their workflow within the current janky hackjob we have, and the slightest change threatens that.

There are suggestions for changes to the skin that would be useful, but the website's design should not be motivated by the navel-gazing within the editor community. It is apparent in many editor discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile. There are discussions for us to have on what the new layout will mean for ToC placement, but we cannot hash out every small detail before first agreeing the adoption of the new layout. There are complaints here about interaction with gadgets and Javascript: this means that those bits of code need to be changed, not the website layout. Many of these gadgets are operating under UI assumptions that are not some functional specification guarantee.

We should not hold back on improvements due to complaints of a vocal minority, but go forwards with the quantitative testing-approved solutions to the problems identified by readers and editors (see below for the WMF's explanation of each stage of this project). — Bilorv (talk) 20:46, 16 July 2022 (UTC)[reply]

discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile - It's possible to give different views for mobile and desktop readers; I don't think we should be catering for mobile to the exception of desktop. I also note that even the current mobile view is less than ideal; I switch to desktop view when reading from mobile because even there it is easier to read the article in that format. BilledMammal (talk) 22:40, 16 July 2022 (UTC)[reply]

I think you've missed my point, BilledMammal, perhaps because I didn't make it clear enough. The issue is not that desktop layout doesn't matter, or that making a good desktop layout contradicts making a good mobile layout. It's that editors generally consider their own layout only (often a desktop layout and specific browser and specific skin) and give no thought to other layouts. As editors, we should be thinking as much about mobile (or more!) as about desktop. But we don't, and that is one example of how editors are not the best people to consult about UI changes. — Bilorv (talk) 08:03, 17 July 2022 (UTC)[reply]

Ah, I see what you are saying now - I fully agree, we do need to consider this on a variety of platforms, and even if it isn't currently suitable for all platforms it may be suitable for some. Below, I have actually asked for some data to be presented separately for desktop and mobile users. BilledMammal (talk) 02:53, 18 July 2022 (UTC)[reply]

Sdkb comments

I've been following/commenting on New Vector throughout the development process and have a lot to say here, so with apologies in advance for the length, I'm creating a subsection.

@SGrabarczuk (WMF) and @OVasileva (WMF): In some other circumstances, I've encouraged the WMF to plunge forward with seeking consensus for deployment, even though development isn't yet complete. My advice here is the opposite: we're not ready for that conversation yet. Users of any site are inherently biased against redesigns, and with Wikipedia's community consensus model, that gives you an unenviable uphill climb if you wish to succeed where past efforts have failed. Because of this, there will be a certain level of guaranteed opposition, and to overcome it, you'll need the design refined enough to get every winnable editor on your side. New Vector has improved a lot over legacy Vector, but I don't think it's at that point yet.

Some of the changes are fairly simple things. For instance, looking at the ToC to the left right now, it ends a ways before the bottom of the page, resulting in an ugly scrollbar that likely could've been avoided if it just extended the full vertical length of the page. Making refinements like that will help avert a gut "this is ugly" reaction and could making the difference between consensus and no consensus.

Other changes are more fundamental. The reduced screen width is something I'm fairly used to at this point, but it seems to be a sticking point with many others. Given that, I think you need to decide how many of the New Vector changes are segmentable. I.e. if the community says "we're okay with everything in New Vector except the screen width" or "we're okay with everything except the ToC", will you be able to implement that? I know you'd prefer to be able to implement everything, but if it has to be an all-or-nothing decision it'll make your task all the harder, because opposition to any one element could foil the entire proposal. So I'd put some thought into what can be segmented out vs. what has to be bundled.

On the ToC, getting it to display so that it doesn't require scrolling in normal cases, even when the main menu is uncollapsed, is something that I predict will be crucial for getting community buy-in. We've been discussing it on MediaWiki, so let's continue the conversation centralized there.

Lastly, I'll reiterate that I think that the upper right corner is going to be a sticking point. We've previously discussed (with Izno and others) how the decision to commandeer that spot for the language switcher appears to have been made based on user research that began with the baseline assumption that making it more prominent was an inherent good, ignoring the other elements that currently occupy that space and that are also important. In your most recent newsletter, you write that the page tabs/title switch moved the language button into an even more prominent position at the top of the page, once again making this assumption, and once again ignoring that you're pushing the other elements down yet another row. When we've brought up those elements, namely coordinates and good/featured article icons, you've declared them out of scope for your project. I don't understand that — you consider it in scope to push them out but not to care about where they're pushed to? Helping readers understand through the site design which articles have undergone a peer review is absolutely crucial for information literacy, and I really wish you'd convene one of your focus groups to understand whether they have any clue about GA/FA currently (my guess is no) and, if not, what can be done through design to fix that (my suggestion is moving them left next to the article name).

If you manage to address these sorts of things, I think it'd be possible to start a productive conversation on making New Vector a default few months from now. That conversation could incorporate multiple steps as you suggest, and it'd probably best take the form of a CENT-listed and watchlist-advertised RfC. If you start it prematurely, though, I think the combination of reasonable and knee-jerk concerns will result in failure to reach consensus, which would set you back. (And I hope it goes without saying that attempting to push through the changes without community consensus would result in a Framgate-level firestorm.) Cheers, {{u|Sdkb}} ^talk 00:34, 14 July 2022 (UTC)[reply]

UX research and usability testing

Note, I am an engineer that uses terminals a lot and I still use the MonoBook skin. But, here's a question. If moving to the new Vector skin is controversial, why not commission and publish an extensive user-centered design case study to prove that the Vector 2022 is actually better. Then the community will have to see reason. (Maybe) Andrevan@ 03:23, 15 July 2022 (UTC)[reply]

Hey all,

A number of you have asked us about our research and testing (both Qualitative and Quantitative), so we wanted to write a pretty detailed and long comment to address this. We wanted to confirm that not only the Growth team conducts complex testing :) This is more like the standard for big projects now. Each feature change has gone through the process below (which we also described in the Signpost in April). This is what gives us the confidence that everything we have built so far is, in principle, an improvement. At the same time, we acknowledge that there's room for more adjustments.

1. Problem identification research with both readers and editors - during this phase, in 2019, we studied the way people used the site and identified the largest usability issues as well as issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries and locations. (See the links: Research and design: Phase 1, Research and design: Phase 2.)
2. Prototype development and testing - this is when we build out the ideas of a feature and begin showing solutions to our audiences. Each feature was tested with readers and editors through interviews and wider rounds of prototype testing. Generally, for testing with editors we used central notice across multiple language Wikipedias so that we can get the widest audience possible. Each prototype was tested by approximately 200 editors on average. (Example)
3. Refining and building - we then take the feedback from the prototype testing and refine or change the prototype based on what needs were identified in the prototype testing. In some cases, we ask for additional feedback during this process so that we’re sure we’re making the right decisions
4. A/B testing and other quantitative testing on pilot (early adopter) wikis - we perform a quantitative test for whether the feature works as expected based on the criteria of success we have previously defined. For example, the sticky header was designed to decrease scrolling to the top of the page. We gave the sticky header to 50% of users and compared them to the other 50% for two weeks. After two weeks we compared the results and identified that that people that had the sticky header were indeed scrolling less to the top of the page in order to select any of the tools available there. If we get negative results from our test, we change the feature and test again. This is the "beta" phase.
5. Finally, we deploy Vector 2022 on more wikis and continue monitoring the way people are using it so that we can flag any issues. In this phase, Vector 2022 isn't "beta" anymore. It's more like a B-class article. Different wikis have different thresholds for B-class, and we believe that in the case of English Wikipedia, we'll be there when the visual refinements and other deployment blockers are ready.

We are currently working on an easy way to explore all of the above data and research (and are welcome to suggestions on the best format). For now, the best way to learn more about the testing is:

• From Reading/Web/Desktop Improvements/Features, select the feature you are most interested in
• Within that feature page, refer to the Qualitative or Quantitative testing section to see the results and our conclusions

Just so we can have a short version of this as a part of this conversation, we're posting a quick list of our learnings:

OVasileva (WMF), SGrabarczuk (WMF) (talk) 16:14, 15 July 2022 (UTC)[reply]

Thank you for posting this; there is a lot to read through so I have only reviewed two features so far, sticky header and persistent table of contents. For the latter, it appears you have yet to conduct A/B testing but when you do I would be interested in seeing data on the percentage of page views that involve at least one click on the table of contents, and the percentage of page views that involve at least two clicks on the table of contents. In addition, I would be interested in seeing separate data for mobile users and desktop users.

For the former, I see you have already conducted A/B testing but there is some additional data that I would like to see:

1. Currently, you show the clicks per session and clicks per page only when skinversion=2; I would be interested in comparing this to the clicks per session and clicks per page for skinversion=1. My hypothesis would be that the sticky_header makes it more convenient for readers to access these links, and thus increases the number of readers using them.
2. The rate of accidental clicks. Assessing this would vary by link, but I have a few ideas and am happy to discuss further if required. My hypothesis would be that the sticky_header increases the number of accidental clicks, and we would need to consider whether this increase offsets the benefits of the sticky_header.
3. Time on page, time on page when limited to pageviews that do not involve following a header link, and time on page when limited to pageviews that involve following a header link. Clicks on pages with stickyHeaderDisabled would need to be split between those that involve a scroll back and those that do not. My hypothesis would be that it does not affect time on page for readers who do not click on a header link, and that it has a small but relatively constant absolute decrease in time on page for readers who follow links on the sticky_header compared to those who scroll back to click on a header link. The former would suggest that this does not negatively affect the reading experience, the latter would suggest that that this has a positive effect on the reading experience for readers who are wanting to navigate to one of those pages.

Alternatively, is there raw data that we can look at from the A/B testing for the sticky header? I suspect it won't answer #2, but it may contain information on #1 and #3.

BilledMammal (talk) 03:33, 17 July 2022 (UTC)[reply]

Has anyone actually used the link given at the very top as "see what it looks like" on a smartphone? For me, instead of getting an encyclopedia article, I get a full screen with the sidebar and no encyclopedic content until I scroll down. Can other people please test this? Because this seems like a quite major bug or worse experience than the current mobile version. Fram (talk) 08:46, 17 July 2022 (UTC)[reply]

Same bug here but only if I'm using the mobile view in a browser. If I'm using the desktop view on mobile it works fine (and actually looks quite nice). With this said, it may be a non-issue as I've not read anything about mobile transitioning away from MinervaNeue. Anarchyte (talk) 09:01, 17 July 2022 (UTC)[reply]

FWIW, I see the same bug as Fram does, on both a Macbook laptop (not mobile) running Safari 14.1.2, and on an Android phone running Opera 69.3.3606.65458 in desktop mode. I just see a banner at the top, a sidebar on the left, and a big blank space on the rest of the page. I have to scroll way down past the sidebar before I see any content, and the content fills the full window width (that is, the sidebar is not to the left of the content, it's above it). There's also no visible TOC on the left side or anywhere, just a hamburger icon that I have to click on to open a TOC. I do not see this bug on Firefox 102.0.1 on a Windows machine. It seems there is still some browser dependency that makes this skin very unpleasant to use in some environments, and not only mobile ones. CodeTalker (talk) 00:51, 18 July 2022 (UTC)[reply]

I've posted an RFC over at Help talk:Citation Style 1#RFC: Rename url-status parameter, proposing to deprecate |url-status= in favor of |archive-display=, a name that better communicates its function and intent. Any community input would be welcome. FeRDNYC (talk) 18:25, 14 July 2022 (UTC)[reply]

Folks,

I enjoy Wikipedia and visit the site regularly. I also contribute to support the fine work you do.

When viewing today's featured article on the Midland Railway War Memorial, I had an idea for what I think would be a new feature for Wikipedia.

My idea would be to be to enable the Wikipedia app to geolocate the user and suggest articles in the vicinity of the user.  That way, when traveling, a person could use Wikipedia to inform them of nearby items of interest and significance.

I still kick myself for the time long ago when I was crossing Wyoming and missed Devils Tower, not knowing it was nearby.  

The Wikipedia app could allow users to sort by distance and by type (natural features, buildings, monuments, historical events, etc.).

That is my suggestion.

Roger 2600:4040:7FCD:C900:6977:6471:32DE:F1EB (talk) 03:32, 15 July 2022 (UTC)[reply]

• 2600:4040:7FCD:C900:6977:6471:32DE:F1EB, there is already Special:Nearby which is a thing on iOS but not sure about android. 0xDeadbeef 03:34, 15 July 2022 (UTC)[reply]
  • Special:Nearby works for me on both firefox for android and bog-standard desktop firefox Caeciliusinhorto-public (talk) 08:15, 15 July 2022 (UTC)[reply]
• Nearby was removed from the android app a few years ago, seems like the support team didn't want to deal with it (c.f. phab:T228661). Special:Nearby does seem to work from the mobile front end website, but I'm not seeing that it is easy to get to for the casual reader... — xaosflux ^Talk 13:46, 15 July 2022 (UTC)[reply]

  Its generally in the mobile website main menu, except for this week, where it is accidentally missing due to some rework that happened. Will be fixed next week, see phab:T312864. —TheDJ (talk • contribs) 13:53, 15 July 2022 (UTC)[reply]

  @TheDJ ahh, thanks for the link - I thought it had been there, just fired up a mobile browser to check and couldn't get to it easily. — xaosflux ^Talk 13:56, 15 July 2022 (UTC)[reply]

The {{authority control}} template is used on nearly 2 million pages, about 4% of all pages. Despite its widespread use, it has long been controversial, having been twice nominated for deletion, in 2010 and 2017. These were based on its uncertain value, its obscure contents, and possible duplication of its function by Wikidata. (I am unsure as to when an article warrants an {{authority control}} template.)

Due to its position in MOS:LAYOUT, it attracts complaints that it looks ugly. The root of the problem here is that it masquerades as a navigation bar but it is not one: Wikipedia:Navigation template states that Navigation templates do not provide external links to other websites. Which is what {{authority control}} does. This is why MOS:LAYOUT places it separate from the navbar templates, but that causes problems with the layout. My proposal is a simple one: to alter the template so it no longer masquerades as a navbar template. So it would look like our other external navigation aid, {{Taxonbar}}. This would resolve issues with its visual impact. Hawkeye7 (discuss) 20:49, 15 July 2022 (UTC)[reply]

• @Hawkeye7: It's difficult to !vote on this without seeing an example or mockup. {{u|Sdkb}} ^talk 15:58, 16 July 2022 (UTC)[reply]

Also note the prior RfC at Wikipedia:Village pump (proposals)/Archive 181#RfC: look of Authority Control. * Pppery * _{it has begun...} 16:11, 16 July 2022 (UTC)[reply]

• The only major visual difference between {{Authority control}} and {{Taxonbar}} is that the former is collapsible. Are you suggesting that function be removed? If so, I object. Removing a helpful function to create a visual distinction is not a good solution. – Scyrme (talk) 19:34, 16 July 2022 (UTC)[reply]

I appreciate your desire not to see it. Here's a mockup:

Despite not being collapsed, it is still smaller than the real thing. The entries are taken from a real article and, yes, some of the links don't go anywhere useful, some of the labels are deceptive, and the layout is inconsistent as well as horrible. That's just the way {{Authority control}} is. Hawkeye7 (discuss) 10:17, 17 July 2022 (UTC)[reply]

I have a question. If Wikidata already does the job that Authority control does, why not use the Wikidata template to auto-fill the authority control? —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:40, 17 July 2022 (UTC)[reply]

... we already do. * Pppery * _{it has begun...} 13:43, 17 July 2022 (UTC)[reply]

Oh I see. The above example is manually filled though, so I thought we only manually fill it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:51, 17 July 2022 (UTC)[reply]

It's only smaller because you only included enough data to fill one line, and the links are unordered into sublists (as they are on eg. Henry VIII). – Scyrme (talk) 01:23, 18 July 2022 (UTC)[reply]

VfD is much clearer, and used on every other wiki. There is no need for it to be different here. – Ilovemydoodle (talk) 06:53, 18 July 2022 (UTC)[reply]