Project:Village Pump

This page is only for discussing issues related to MediaWiki.org site.

To get help with MediaWiki software, ask on Project:Support desk.

Hi everyone! We are the Wikimedia Foundation Web team. We work on making it easier to read Wikimedia projects as part of the objective "Reading and media experience". To achieve this goal, we have introduced the "Accessibility for Reading" beta feature. It adds a menu which works on the Vector 2022 skin and allows logged-in users to choose different font sizes based on individual needs. This makes it easier to serve the accessibility needs for more people. For more information, check out our project page.

The menu introduces a new Standard font setting. It slightly increases the size and height of the font. It was selected by looking at the preferences of editors using the beta feature, general recommendations for accessibility (which font is quickest to read for the majority of people), as well as the suggestions and designs of more than 600 Wikimedians. You will find more information on this setting below. This menu has been available on Wikipedias since June 2024.

We are now ready to make the new Appearance menu available for logged-out and logged-in users on all wikis, including this one. At the same time, we will also make the Standard option the new default for logged-out users only. If no breaking technical issues are found, we plan on making this change in the week of September 9.

About the menu

The new menu will allow logged-in and logged-out users to set preferences for: Text size and line height (available now as the beta feature): Users will be able to choose between the Small (current default), Standard (recommended for better accessibility), and Large options. Selecting an option will change both the font size and line height of the text. Content width (previously available as a toggle button): We have moved the content width toggle from an icon at the bottom of the page to a labeled radio button in the new menu. It will work exactly the same as the toggle. The previous toggle button will no longer be available. Dark mode (coming soon!): Users will be able to choose to see the site in night mode on a permanent basis, or select an “automatic” setting which will set day or night mode based on the device or browser preferences. Dark mode is already available in the menu as a beta feature - check it out by opting into the “Accessibility fo Reading” This menu has been tested as a beta feature by logged-in users across wikis as well as in user testing with readers. The menu has also been the default on all Wikipedias since June 2024. Based on the findings of these tests, we changed the menu to improve the user experience, menu discoverability and ease of use, and to accommodate gadget compatibility across wikis. The menu will appear to the right of the page, immediately under the Tools menu. Similar to the Tools menu, the menu will appear as open by default, but can be pinned. Once pinned, the menu collapses under an icon at the top of the page.

About the new Standard font setting

The "Small" option is the current default. We will be changing this default to "Standard" for logged-out users, while keeping "Small" as the default for logged-in users. The "Standard" and "Large" options were built and tested based on the following: Academic studies and recommendations for the best average font size for the majority of readers. These recommendations stated that our current size is too small for the majority of people to read comfortably. This means that on average, people read more slowly, strain their eyes while reading, or have difficulty clearly seeing the text. Increasing the font size by default improves these issues for all users, including users who might not have sufficient time to spend adjusting a setting via the appearance menu or browser. We also highlighted that information density is important to the Wikipedia experience, making the goal of the typography changes to increase font size without sacrificing information density. This was done by altering not only font size, but also line height and paragraph spacing. Designs submitted by more than 630 Wikimedians from across 13 wikis of different languages, scripts, and sizes. The majority (~450) of test users opted for a font size that was larger than the default, with the most popular cluster being 15-20 pixels. "Standard" represents the average of the most popular cluster of community responses (15-20) pixels. "Large"represents the need for an even larger option, as represented by the cluster of sizes between 21-26 pixels. You can read more on how we included volunteers in the process and landed on these options. Beta feature usage showed that the majority of users who interact with the feature at least once opt for a font size that is larger than the current default.

Our works so far and next steps

Logged-in users will remain with the “small” setting for the time being as their default, but can change to any other setting at any time. In a few months, we will study how many logged-in users switch to standard and start a conversation on whether it makes sense for logged-in users to make the switch as well. From the early data from the beta feature, 55% of sessions who interacted with the feature chose to use a setting that was standard or larger.

If you'd like to help, we have a few simple requests for you:

1. Please, turn on the beta feature ("Accessibility for Reading (Vector 2022)")
2. Try out the new menu. Is anything confusing? Do you understand all the labels and how the menu works?
3. Try out the small, standard, and large sizes. Reach out to us if you notice any bugs, or have questions or concerns.
4. Try out the width toggle. Reach out to us if you notice any bugs, or have questions or concerns.

If you'd like to learn more about the project, see our FAQ. Comments and questions are most welcome. Thank you!

Is it somehow possible to disable this annoying feature? It is unproductive to offer users on each visit a selection of appearance preferences, forcefully narrowing visitors screen with this aggressive setting list. I can't believe that anyone ever asked this feature! Please, disable this menu for logged out users and unregistered users!

You can always hide the menu (convert the sidebar section to a button at the top of the page) using the hide button, and this hiding is sticky (as far as I remember, also for unregistered/logged-out users), i.e. once you’ve hidden it, future page loads will initially hide it (but, of course, you can also stickily unhide it, should you change your mind). Actually, the above screenshot shows it in the “hidden” state: in the state in which it’s a button at the top of the page, and it’s only temporarily open without being unhidden.

The Hide button hides the menu for that visit only. Next time the menu is back again.

Not for me. I hid the menu on English Wikipedia in a browser I’m not logged in, restarted the browser, and the menu was still hidden. Maybe you regularly delete cookies? The software can’t do anything if you destroy your preferences.

I never delete all cookies, only for particular sites, when there is an issue with the site. I did not delete Wikipedia cookies.

I experience the return of the menu when returning to the site after my computer has been switched off or hibernated. My computer assigns automatically different IP6 address from time to time, this may be somehow related.

The issue is also there if you often visit Wikipedia different language versions.

Almost every different language version brings up this menu again.

Flow is (sometime soon) going to be archived and undeployed from Wikipedia, which is going to involve a maintenance script moving every Flow page to a subpage and adding wikitext placeholder (phab:T371738). I'm thinking about, before that happens, running a bot to:

1. Delete Flow pages that have an empty header and zero topics (like Talk:Wikimedia Release Engineering Team/SSD Sync Up/2019-03-05)
2. Delete Flow pages that have no content other than a pointer to a /LQT Archive 1 page, and delete the /LQT Archive 1 page as well (like Extension talk:Vandal Brake and Extension talk:Vandal Brake/LQT Archive 1)

There are several hundred total of each type of page. I deleted a bunch manually earlier today.

Does this seem like a good idea.

and delete the /LQT Archive 1 page as well

...where the LQT archive page is empty as well, right?

Other than that, I agree, there's no reason to keep these empty pages around, especially if the maintenance script isn't going to attempt to delete them itself.

In said cases the /LQT Archive 1 should always be empty since if it had content it would have been copied to the Flow page. But yes I should check explicitly.

I reviewed the LQT archive 1 pages with substantive content. In a few places the Flow page was empty so I deleted the Flow page and moved the LQT archive over the Flow page (and removed the archive template). And there were a lot of other oddities.

Probably a lot of the /LQT Archive 1 pages can be deleted too (even if there is a Flow page with content it was based off of), since the vast majority of them have no content other than someone adding LiquidThreads, and then Flow replacing it.

Most of the ones that don't meet that description either contain only a pointer to old pre-anything archives (which are already in the Flow header). And there's a few cases where the LQT page contains wikitext because people mixed systems I guess ...

I've continued reviewing a bunch of Flow pages. There are several thousands pages to delete per the above criteria. And I manually deleted a ton of old leftover crap of every imaginable kind

What should be done with pages like User_talk:Thennicke that contain nothing other than a pointer to a wikitext archive, in user talk namespace? These differ from the /LQT cases because the user explicitly enabled Flow. I'm inclined to delete the Flow board, move the wikitext archive back to the base title, and remove the {{Archive }} template. The other option would be to do nothing and let the migration script handle it.

It also seems to be worthwhile to batch delete user talk pages that contain only the header and no Flow topics where the user in question has made few other edits. There are several thousand of them.

I manually reviewed the first ~100 cases of user talk pages that contain only the header and except for the above situation (repeated several times) every single one was either spam/out-of-scope/test edits that I deleted on-sight or some kind of useless platitude like "talk to me here", which I didn't bother pressing the delete button on but isn't worth letting the migration script move to a subpage on either.

There are a total of 5031 empty flow boards, 297 boards with nothing other than /LQT placeholders, and 722 user talk pages containing only a header of users with <50 global edits.

It's getting difficult to see recent changes due to the massive number of category translation pages being churned out by FuzzyBot. In the filters I have human not bot selected and bot edits unselected, so bots should be hidden (and those settings haven't changed in a long time either). FuzzyBot is still indeed a bot too. Is this just me or are filters not working currently?

Yeah, I noticed the same thing. Apparently you have to explicitly specify an edit is a bot edit when making edits via internal PHP code, and I failed to realize this when I wrote the patch that caused FuzzyBot to do this. You can work around the issue by deselecting "page creations".

Flood has stopped now.

Indeed it has! Thanks.

We seem to want to keep things as is. This has now been codified at m:Global sysops/Local discussions

In 2021, without any discussion I can find, Leaderboard added This is a wiki that has opted in to allowing global sysops to work here without any discussion I can find. This wiki does not actually meet the default provisions for allowing global sysops (it has 137 admins, and 49 active), and was added to the global sysop wikiset in 2010 (m:Special:Log/1079847) without any apparent local discussion. Likewise, the reference to global sysops at Project:Administrators was added in 2010 (Special:Diff/307909) again as a factual statement without any apparent local discussion. I'm in the process of doing an audit of which wikis are global sysop wikis which is going to end up posted at m:SN#Global sysop set audit.

Personally I think it's fine to have global sysops here, but in order to keep the records straight we should formally codify that somewhere. So, what does everyone else think?

Support global sysops (+ other associated rights) rather strongly. I'm guessing that any discussion regarding this in 2010 was held off-wiki?

It's been like this for decades without opposition, surely there is no actual need for a confirmation discussion at this time, unless someone wants to change it?

I don't see any need to change things either.

Me neither. Most admins do not check administrative pages a lot, and specially in the 02:00 and 11:00 UTC timeslot. Technically the wiki no longer meet GS scope with relatively active admins.

Seems to have been fixed.

Im very very new to here so im sorry if its wrong place, someone made a typo while trasnlating decrips of watchlist filters to turkish language, it says Lzleme Listenizdeki instead of İzleme Listenizdeki.

Each year, typically from October through December, several of the movement’s committees seek new volunteers.

Read more about the committees on their Meta-wiki pages:

• Affiliations Committee (AffCom)
• Ombuds commission (OC)
• Case Review Committee (CRC)

Applications for the committees open on 16 October 2024. Applications for the Affiliations Committee close on 18 November 2024, and applications for the Ombuds commission and the Case Review Committee close on 2 December 2024. Learn how to apply by visiting the appointment page on Meta-wiki. Post to the talk page or email cst@wikimedia.org with any questions you may have.

For the Committee Support team,

-- Keegan (WMF) (talk) 23:07, 16 October 2024 (UTC)

Hello all,

Thank you to everyone who participated in the 2024 Wikimedia Foundation Board of Trustees election. Close to 6000 community members from more than 180 wiki projects have voted.

The following four candidates were the most voted:

1. Christel Steigenberger
2. Maciej Artur Nadzikiewicz
3. Victoria Doronina
4. Lorenzo Losa

While these candidates have been ranked through the vote, they still need to be appointed to the Board of Trustees. They need to pass a successful background check and meet the qualifications outlined in the Bylaws. New trustees will be appointed at the next Board meeting in December 2024.

Learn more about the results on Meta-Wiki.

Best regards,

The Elections Committee and Board Selection Working Group

MPossoupe_(WMF) 08:24, 14 October 2024 (UTC)

Moved discussion from Project:Support desk: Topic:Ycnzkboml8e897kr.

Where to put orphaned Manual:File page warnings in Manual:Contents?

Suggestion from @Shirayuki: "Since the only page passing both dev=y and admin=y in {{Hubs}} is Manual:Maintenance scripts, I personally think it would be good to place it near that."

Done

Post close note by RhinosF1: request was made by a globally banned user and is under review

We have created a new wikihoster, but I can't because abuse filter believes that my edit it's spam. Could you add "|- | SkyWiki | USA | farm | | style="background:#9F9;vertical-align:middle;text-align:center;" class="table-yes" | Yes | style="background:#9F9;vertical-align:middle;text-align:center;" class="table-yes" | Yes, or subdomain | free (no ads) | Discord server | | Extension install on request, after security review. No hard limits on server resource usage and runs latest MediaWiki version." on this page please?

can someone please add it to the list

Feel free.

@clump unfortunately can't due to abuse filter

Hmm...you have 74 edits here, so you should be able to...

Editing the main namespace is limited for new users. This site is for documenting the MediaWiki software. It is not the wiki that you set up for your class, workplace, or personal use, nor is it Wikipedia. If you want to create a Wikipedia article, please start here. Think this is an error? Ask at Project:Village pump.

Stop trying to write an unsourced, spammy article on your company. Wikimedia is not a venue for self-promotion.