This page is only for discussing issues related to MediaWiki.org site.
Archives
|
|---|
|
|
For the extensions developed by us (HalloWelt), we would like to add a template to the extension talk pages that refers support questions to our external support site.
We want to consolidate our efforts to support the community and since we already have a place where we offer free support, we need a way to redirect questions there. Otherwise, questions tend to get overlooked.
Does anyone see an issue with adding such a template?
@MLRodrigue: As a starter, I've created Template:External help for this – is that sufficient?
Hello everyone,
The next language community meeting is coming up next week, on November 29th, at 16:00 UTC (Zonestamp! For your timezone <https://zonestamp.toolforge.org/1732896000>). If you're interested in joining, you can sign up on this wiki page: <https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/Community_meetings#29_November_2024>.
This participant-driven meeting will be organized by the Wikimedia Foundation’s Language Product Localization team and the Language Diversity Hub. There will be presentations on topics like developing language keyboards, the creation of the Moore Wikipedia, and the language support track at Wiki Indaba. We will also have members from the Wayuunaiki community joining us to share their experiences with the Incubator and as a new community within our movement. This meeting will have a Spanish interpretation.
Looking forward to seeing you at the language community meeting! Cheers, Srishti 19:53, 21 November 2024 (UTC)
It's seven days and OP hasn't explained why, unlikely to be implemented.
the message should be more detailed like enwiki
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."
Hello all,
The scrutineers have finished reviewing the vote and the Elections Committee have certified the results for the Universal Code of Conduct Coordinating Committee (U4C) special election.
I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:
The following seats were not filled during this special election:
Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.
Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. You can follow their work on Meta-Wiki.
On behalf of the U4C and the Elections Committee,
RamzyM (WMF) 14:05, 2 September 2024 (UTC)
I want to add a link to my Bilibili account's home(at my Mediawiki account home). But I can't create a link.
Unlikely to happen in our collective lifetimes.
Running maintenance scripts directly is deprecated since MW 1.40, and instead we're told to use "php maintenance/run.php someScript.php". However, the MW documentation is obsolete in this respect and it still uses the old form virtually everywhere, I'd like to address that but there's no way I'm editing hundreds of pages one by one.
If someone were to install Extension:Replace_Text or equivalent and grant access to it for autoconfirmed users I'd be glad to do it, though.
Adding new extensions to the wiki farm is a very difficult process and generally not done. w:Wikipedia:AutoWikiBrowser is probably your best bet here.
This wiki doesn't have any formal approval process for it, so you can even set it to auto-save (if you really think the edits are simple enough to be done purely automatically, which I'm not 100% sure of)
OK, I may try that then. Anyway even if the bureaucracy red tape wasn't there I guess granting access to ReplaceText for autoconfirmed users here would have never been done I suppose. Oh well.
Thanks.
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:
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.
Let's get rid of at least the empty stuff. Those 722 can go as well as far as I'm concerned, but we might want a bit more review and consensus on that ?
It should be possible to update the maintenance script so that it automatically deletes Flow pages that have an empty header and zero topics. I see you (Pppery) commented about that at phab:T371738#10286448 already, so I'm just confirming that it is being looked into by the team.
For the completely-empty pages, I wonder if we might want to delete them without-log-entry, so that the empty wikitext page doesn't have the "this page was deleted" banner at the top as a cluttering-distraction? I believe that is technically possible. --- If folks here agree that this is a good idea, then we can ask the team to make it so.
For the "almost empty" pages, I agree those would need to be examined manually. Personally, I agree with both of you that those pages can probably just be deleted, once they've been checked for edge-cases.
Thanks again for all your associated efforts and thoughts on this, Pppery! It's deeply appreciated.
I think deleting things without producing a log entry is downright scary and contrary to the wiki way of every action being logged.
On other issues, I assumed from the fact that my comment on phab:T371738#10215964 wasn't responded to and a maintenance script was merged and run without doing any of those things that the WMF was disclaiming interest in implementing them and thus the task fell to me to do it myself - I was prepared to run Project:Requests for permissions/Flow cleanup bot (and still am).
Even if the WMF does do that, though, I learned quite a bit from this experience, and the code I wrote there I also used to manually clean up a bunch of pages that really did need manual review.
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:
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:
|
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:
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.
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".
