Movatterモバイル変換

[0]ホーム
URL:

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview
List overview
Download

Wikitech-lSeptember 2025

wikitech-l@lists.wikimedia.org
  • 19 participants
  • 24 discussions
Start a nNew thread
TLDR: Mobile devices will receive the mobile version directly on the standard domain, instead of via a redirect to the mobile subdomain. The change is live in the Beta Cluster and on test wikis, and expected to follow a train-like rollout over the next few weeks.Today, when you visit a link to a wiki (likeen.wikipedia.org), the server responds in one of two ways: a desktop page, or a redirect to the equivalent mobile URL (likeen.m.wikipedia.org). This mobile URL in turn serves the mobile version of the page from MediaWiki. Our CDN operates this way since 2011, when we enabled MobileFrontend by default. Diagram: Unified mobile routing - before and after <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…>This redirect causes a number of problems, [2] such as: • User experience: Links shared by mobile users always display in mobile mode instead of the mode for your device, even after opt-out. • Site performance: Every Google Search result click is delayed by the redirect before displaying the article. • SEO: There is a conflict in our link graph because standard URLs redirect to mobile, and mobile sets a canonical pointer back to the standard URL. This de-indexes or mis-indexes pages in Google. T400022 <https://phabricator.wikimedia.org/T400022> • Infrastructure cost: MediaWiki sends twice as many purges to our CDN infrastructure. • Technical debt and known issues (e.g. incompatibility with OAuth). [3]Over the next few weeks, the CDN will serve the mobile version directly, without first redirecting the browser to the mobile subdomain. What is not changing • Backend code may detect mobile mode via `MobileContext->shouldDisplayMobile()`. • Frontend code may detect mobile mode via `mw.config.get('wgMFMode')`. [4] • Third-party MediaWiki sites. This is a WMF configuration change only. • Mobile requests to MediaWiki (identical HTTP host and headers). • Existing mobile URLs continue to work. • The "Desktop" opt-out footer link. • The speed of light.Backend requests unchangedThe mobile subdomain on WMF wikis is only recognised by Varnish (Wikimedia CDN). Varnish strips this "m" from the domain, activates MobileFrontend, and forwards the request to MediaWiki with the standard domain. [1]This means MediaWiki core and extensions know how to handle mobile requests on the standard domain, because that's how it already works. It also means that the change is not observable (through supported means) by backend feature code in MediaWiki, because the mobile subdomains don't exist there.What should I test?If your gadget or MediaWiki extension does not vary its behavior for mobile, or detects mobile mode using the supported mechanism listed above, then you're all set.Note that Minerva-specific or mobile-specific code in a MediaWiki extension is naturally compatible with unified mobile routing, if it was tested locally or in CI. When you install Minerva (and optionally MobileFrontend) in your dev environment, they operate without a mobile subdomain by default. • There is (probably) no mobile domain in your local dev environment. • There is no mobile domain in Patch demo. • There is no mobile domain in CI.This infrastructure change aligns WMF production with how MediaWiki and MobileFrontend work by default. This decreases the potential for bugs we have today that can be exclusively found in production (via the mobile subdomain), and resolves a backlog of existing known issues. [3]Unsupported checks in frontend codeIf a JavaScript-based feature contains a hardcoded `m.` hostname check, then this will no longer match in the future. The most likely place to find hardcoded `m.` checks is in a gadget or user script that changes its appearance or logic for mobile pages.Detecting the mobile mode in this way is unsupported and should be replaced with a supported mechanism <https://phabricator.wikimedia.org/T390923> instead. [4] An audit in April 2025 found there were 2 WMF-deployed extensions using this, which were confirmed to fallback gracefully or have since been adjusted. [5]Where can I test?The new unified mobile routing is live on these wikis: • Beta Cluster athttps://beta.wmcloud.org • test wikis athttps://test.wikipedia.org andhttps://test.wikidata.org •https://wikitech.wikimedia.org •https://office.wikimedia.org •https://www.mediawiki.orgFor other production wikis, such asen.wikipedia.org, you can preview the change today by adding `?useformat=mobile` to a URL. This activates MobileFrontend on the standard domain, like it would in the future. For example:https://en.wikipedia.org/wiki/Banana?useformat=mobile.The timeline <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> spans several weeks and should not require dedicated testing. If you're unsure, you can test on the pilot wikis above, or in production via the `useformat=mobile` parameter. f you find a bug with mobile toggling or another regression, please report a bug to Phabricator. If you have questions or need help with a gadget or user script, please reach out on the talk page <https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Mobile_domain_suns…>. -- Timo Tijhof🔗 Read or share this post on the web via:https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…[1]: Diagram of mobile routing before and after <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> [2]: Problem statement and analysis onmediawiki.org <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…>[3]: Known issues listed in the Phabricator task <https://phabricator.wikimedia.org/T214998>[4]: Remember that mobile detection should be rare in frontend code, because most differences are between skins (Minerva vs another skin) and not MobileFrontend.[5]: Audit of unsupported m-dot checks in JavaScript <https://phabricator.wikimedia.org/T390923>
2 2
1 0
Phabricator improvements
by Andre Klapper 20 Nov '25

20 Nov '25
I am excited to announce that this is an exciting announcement.Today the Wikimedia Release Engineering Team deployed a larger softwareupgrade ofhttps://phabricator.wikimedia.orgYou now better enjoy * Performance improvements: - Global fulltext Search ignores data of uninstalled Phab apps - Embedded full size image files are lazy loaded - Using DNS preconnect for our separate file domain - Faster rendering of Project Burndown tabular reports * Search user interface: - "Advanced Search" renamed to Global Search and application search - Global Search Scope dropdown: "Current Application" replaced by the actual app name; no more such option when the app does not support global fulltext search - Maniphest Task Search does not anymore show unused "Packages" and "Owners" when using typeahead in the "Subscribers" search field - Ctrl+Return in text boxes opens search results in a new tab * User Profile pages: - New "Authored Tasks" one-click menu item in sidebar - Less ambiguous menu item names in sidebar - Support for images in WebP format as avatars - (admins only): One-click menu item to view Activity Log of user - (admins only): User's Two-Factor Auth status shown on profile page * Project Workboards: - Those numbers in workboard column headers have now tooltips - Archived projects are now strike-through in navigation breadcrumbs - Automated Column Triggers: Allow setting the user who performs the move as task assignee - Thinner scrollbars in Firefox on Windows - Importing columns: No more crash when typeahead querying projects and search string is not a project name prefix - The "Move Tasks" action now requires "Can Bulk Edit Tasks" rights * Herald automated actions: - New condition "Acting user's projects" available - No more "Unknown Object (????)" for custom field values in editor * General text input: - No more text suddenly disappearing when writing {{#something:}} - Stripped surrounding whitespace when entering project or task titles - Support for "size=thumb" parameter when embedding video files * Conduit API: - Support search select fields as constraints, e.g. "Group By" in maniphest.search, project status in project.search, status and hosted in diffusion.repository.search - Improved documentation of types in transaction.search * User Preferences: - Email: No more useless "Audits" section (we uninstalled that app) - External Accounts: Shows tooltips for buttons - Multi-Factor Auth: Explains consequences of adding a second factor * Projects: - Profile images: Show maximum picture dimensions at uploading - No more "set this color to Red" message editing archived projects - No more 404 error on URLs with an alternative hashtag of a milestone * Project Report Charts: - Rotated x-axis labels for better readability - Improved line colors * Files: - Support rendering images in WebP format - List of uploads includes the timestamp, not only the date * Mobile: Support zooming on pages (e.g. when looking at image files) * Mobile: Detection of Firefox on Android (to adjust content width) * Tokens: Allow filtering given tokens by token types * Wikibugs IRC bot: Report the color of milestones correctly * (admins only) Allow changing email of bot and mailing list accounts * Numerous crasher fixes * Some accessibility improvements (ARIA labels, titles, etc) * Cleaner CSS (less noise in your browser's Developer Tools' console)Our Downstream dependency trees of tasks are athttps://phabricator.wikimedia.org/T386558 andhttps://phabricator.wikimedia.org/T393840I'd like to thank the Wikimedians BlankEclair, mainframe98, MatmaRex,pppery, taavi, valerio.bozzolan, xtex, who contributed patches to theupstream project athttps://we.phorge.it. (Hope I forgot nobody?)As usual, if you have comments or questions about Phab, please bringthem up onhttps://www.mediawiki.org/wiki/Talk:Phabricator/Help !Cheers,andre (on behalf of the Wikimedia Release Engineering Team)-- Andre Klapper (he/him) | Bugwranglerhttps://blogs.gnome.org/aklapper/
3 3
0 0
Hey everyone,I’ve noticed a lot of students (including myself) struggling with the pressure of online classes, deadlines, and quizzes — especially with platforms like Capella FlexPath, WGU, and others.If you're overwhelmed, there’s a service I recently came across called Online Classes Help. They assist with everything from discussion posts and assignments to full course completion. Super helpful for those juggling jobs or other responsibilities!Whether you need one-time help or ongoing support, this could really reduce your stress and help you maintain a good GPA. Just make sure to use it ethically — as a support tool, not a shortcut!Has anyone else tried such services? Would love to hear your experiences.Cheers! fpr more info :https://coursefpx.com/online-class-help/
2 2
0 0
Hello,We will perform maintenance on Gerrit on *Monday, October 6*, from *12:00to 13:00 UTC*.During this window, we expect a *~20 minutes* write outage while we switchover Gerrit's service from the current primary (gerrit1003) to the sparehost (gerrit2003).Since last time, we've added a few guardrails: - Local emergency backup on each instance. - All instances will be *read-only during the switchover *to protect data integrity. - Pre- and post-switch checks to verify everything is in the expected state.As before, we’ll perform the switchover *live with Release Engineering*.This operation will allow us to unblock a few things: - System daemon user: *gerrit2 → gerrit (*T338470 <https://phabricator.wikimedia.org/T338470>) - *OS upgrade* (T392464 <https://phabricator.wikimedia.org/T392464>, T384595 <https://phabricator.wikimedia.org/T384595>)*, Java* (T392465 <https://phabricator.wikimedia.org/T392465>) version update and *Gerrit * (T379714 <https://phabricator.wikimedia.org/T379714>, T392448 <https://phabricator.wikimedia.org/T392448>) version update*Expected impact* - A ~20 minutes *read-only* window; reads (browsing, cloning, reviewing) should remain fine. Pushes, votes, comments, etc. will be blocked during that period - We’ll post start/end updates during the window.*Links* - Documentation:https://wikitech.wikimedia.org/wiki/Gerrit/Operations#Switch_over - Phabricator:https://phabricator.wikimedia.org/T387833 - Deployment Calendar:https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20251006T1200Thank you for your understanding.--*Arnaud Bran* (he/him)Senior Site Reliability EngineerWikimedia Foundation <https://wikimediafoundation.org/>
2 5
0 0
Hello everyone,Short version:We will be upgrading the eqiad Wikikube kubernetes<https://wikitech.wikimedia.org/wiki/Kubernetes/Clusters#WikiKube> clusterto 1.31 on Wednesday 2025-10-01 starting at 10:00 UTC<https://zonestamp.toolforge.org/1759312800>, ending at 15:00 UTC<https://zonestamp.toolforge.org/1759330800>.Toolhub will be down during this maintenance.If you are deploying services to the eqiad Wikikube kubernetes cluster: - Deployments will be unavailable during the maintenance. DO NOT DEPLOY. - SRE will redeploy all services - SRE will announce the end of maintenance, at which point the cluster will be usable again---Object: Kubernetes upgrade to 1.31Target: eqiad Wikikube clusterMaintenance window: 2025-10-01 10:00<https://zonestamp.toolforge.org/1759312800>-15:00<https://zonestamp.toolforge.org/1759330800> UTCTracking task: Phabricator at ⚓T405703 Update wikikube eqiad to kubernetes1.31 <https://phabricator.wikimedia.org/T405703>Operational channel: IRC #wikimedia-sre<https://web.libera.chat/gamja/?nick=Guest#wikimedia-sre>, announcementswill be made to IRC #wikimedia-operations<https://web.libera.chat/gamja/?nick=Guest#wikimedia-operations>Operating team: SRE ServiceOps (contact IRC #wikimedia-serviceops<https://web.libera.chat/gamja/?nick=Guest#wikimedia-serviceops>)Impact:Users: - Toolhub will be down for the duration of the window. - No user impact for other services.Deployers: - Deployments to the target cluster will be unavailable. This includes MediaWiki backports and deployments. DO NOT DEPLOY. - The following deployment windows are cancelled: - Services: Citoid/Zotero 11:00 UTC <https://zonestamp.toolforge.org/1759316400> - UTC Afternoon Backport Window 13:00 UTC <https://zonestamp.toolforge.org/1759330800> - Wikifunctions Services UTC Afternoon 14:00 UTC <https://zonestamp.toolforge.org/1759327200>Process:All steps handled by SRE ServiceOps - Maintenance start is announced on #wikimedia-operations and as reply to this email chain - All deployments are stopped - SRE ServiceOps ensures all current versions of deployments can be safely deployed - Maintenance begins and should take a couple of hours - Toolhub downtime starts - Cluster is wiped and upgraded - Toolhub is redeployed first to minimize downtime - Toolhub downtime stops - SRE ServiceOps redeploys all target cluster services - Maintenance end is announced on #wikimedia-operations and as reply to this email chain - Deployments resumeRationale:The date was chosen for convenience as due to the data center switchoverprocess <https://wikitech.wikimedia.org/wiki/Switch_Datacenter>, eqiad iscurrently fully depooled, receiving almost no traffic. eqiad is scheduledto be repooled on 2025-10-02 <https://zonestamp.toolforge.org/1759417200>,which would complicate the upgrade. With eqiad already drained, we expectno visible user impact.SRE ServiceOps will be checking that all services can be safely deployedbefore the maintenance, and will be redeploying all services before markingthe cluster as usable. Deployers are not required to re-deploy theirservices, unless they have been informed to do so by SRE ServiceOps.During last week’s switchover <https://phabricator.wikimedia.org/T399891>,Toolhub remained in eqiad. This means that there will be an expectedunavoidable small downtime of a few hours. To minimize Toolhub’s downtime,we will prioritize its redeployment during the initialization phase.Thank you for your understanding and support! If you have any questionsregarding this process, please respond to this email, comment onPhabricator at ⚓T405703 Update wikikube eqiad to kubernetes 1.31<https://phabricator.wikimedia.org/T405703>, or reach out directly to me(IRC nickname claime on #wikimedia-serviceops<https://web.libera.chat/gamja/?nick=Guest#wikimedia-serviceops>).On behalf of SRE ServiceOps,-- Clément 'claime' Goubert (they/them)Senior SREWikimedia Foundation
1 4
0 0
Hello all!The Search Platform Team usually holds an open meeting on the firstWednesday of each month. Come talk to us about anything related toWikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons QueryService (WCQS), etc.!Feel free to add your items to the Etherpad Agenda for the next meeting.Details for our next meeting: Date: Wednesday, October 1, 2025 Time: 15:00-16:00 UTC / 08:00 PST / 11:00 EST / 17:00 CET Etherpad:https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link:https://meet.google.com/vgj-bbeb-uyi Join by phone:https://tel.meet/vgj-bbeb-uyi?pin=8118110806927Have fun and see you soon!-- *Guillaume Lederrey* (he/him)Engineering ManagerWikimedia Foundation <https://wikimediafoundation.org/>
1 1
0 0
Hi all,we're movingirc.wikimedia.org to a new infrastructure [1]. Thisservice is unrelated to the IRC network (Libera) we use for real timediscussions. Insteadirc.wikimedia.org is an IRC service forbroadcasting recent changes events from public Wikimedia wikis to beused by various bots connected to per-wiki IRC channels.irc.wikimedia.org should not be used for any new bots (which shouldrather use Eventstreams[2]), but we still have various important botsrelying on the legacy IRC-based infrastructure.The current setup is full of technical debt and ultimately based on apatched version of a very old release of ircd-ratbox with a relayservice written in Python 2.We are replacing it with a modern standalone implementation in Python,which broadcasts IRC notifications in a format compatible to what iscurrently in use by the legacy setup:https://github.com/paravoid/ircstreamLast week during the SRE Infrastructure Foundations hackathon theircstream production setup was created. All our tests have beensuccessful, so on Thursday October 10 at 08:00 UTC we'll switch theirc.wikimedia.org DNS name to the new setup.No changes are needed to any bots, but if you run into any issuesafter the switch, please notify us in the #wikimedia-sre-foundationsIRC channel or leave a note athttps://phabricator.wikimedia.org/T376014.Cheers,Luca, Simon and MoritzFootnotes:[1]https://wikitech.wikimedia.org/wiki/Irc.wikimedia.org[2]https://wikitech.wikimedia.org/wiki/Event_Platform/EventStreams_HTTP_Service
4 3
0 0
Hi everyone,TL;DRSRE will be co-owning, together with Thomas Chin of Data PlatformEngineering, the service-utils<https://www.mediawiki.org/wiki/Service-utils> Node.js utilities library,service-runner <https://www.mediawiki.org/wiki/Service-runner>'s spiritualsuccessor and replacement. If you are thinking about starting a new Node.jsservice to be deployed in production, using service-utils is expected togreatly reduce friction, speed up development and allow you to focus onyour business needs instead of how to satisfy SRE requirements for gettingthe service deployed. If you already own one or more services that is (are)service-runner powered, consider migrating to service-utils at yourconvenience.BackgroundService-runner <https://github.com/wikimedia/service-runner> is a librarythat provides generalized runtime facilities for Node.js services,including: - a standard worker cluster setup with restarts, - a generalized YAML config format with support for running multiple services in a single process, - runtime facilities for - logging - metrics reporting - rate limiting.Usage in Foundation produced code and micro services is thought to haveincreased the productivity of developer and SRE teams by abstracting andautomating away, the important but unrelated to the actual goals of thedeveloper teams, requirements mentioned above. Ongoing support from theowning team, which is no longer extant, the Services team, also played apivotal role.Out of the 20 NodeJS apps (powering 25 services), 15 currently use it(those not using it are either pioneering service-utils already or aretrying out other solutions).Unfortunately, it is also abandoned. Node.js developers have noticed andthe Phabricator workboard<https://phabricator.wikimedia.org/project/view/1062/> makes this evident,with Task Titles like "service-runner has vulnerable and outdateddependencies", "service-runner depends on preq, a wrapper of request, whichis deprecated". Some efforts have been made to find a replacement.Thomas Chin has been kind enough to create service-utils, a librarydesigned to be compatible (if not a drop-in replacement in many cases) withservice-runner. However, maintaining this library isn't Thomas' nor theData Platform Engineering team's mission. This has, unsurprisingly, led tolower than wished for (by SRE at least) adoption.Next stepsSRE will be, starting in Q2 2025-2026 - Becoming more familiar with the code base - Updating documentation as needed. - Helping with ongoing maintenance of the library - Providing help and guidance for migration from service-runner to service-utils - Going through the backlog of work tracked in the corresponding Phabricator work boards for the 2 projects and implement/resolve bug/decline/stall as deemed appropriate, always after discussions with relevant stakeholders. - Contributing the following features they are interested in: - Abstracting away talking to the service-mesh - Finish testing and rolling out support for Open Telemetry - Announcing the full deprecation of service-runner, archival of code repositories and removal from library repositories (i.e. npm) when all, in scope, code bases have been migrated over.FAQIs this a full drop-in replacement?No. It's close enough for most use cases. However, service-runner is adecade old code base. Some of the functionalities it provides either nolonger make sense in 2025 (e.g. worker cluster setup in a Kubernetesenvironment is not needed), made assumptions about the Infrastructure thatno longer apply (e.g. rate limiting) or rely on entirely abandoned andnon-salvageable libraries (e.g. kad that implements rate limiting). Thoseare not and will not be supported in service-utils.When should my team migrate to/adopt this?If you start a new Node.Js service in the WMF, go for this from day 1. Ifyou already run a service-runner powered service, at your earliestconvenience.Who do I talk to if I want some functionality implemented before I adoptthis?Faster path forward is probably to come to either #wikimedia-sre on IRC or#talk-to-sre in Slack. SRE Service operations will respond.Is this tracked in the annual plan?Yes, most work is already under KR WE6.2, aka Production Readiness<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2025-2026/…>.Some parts of the work described above will be ongoing and tracked underAnnual Essential Work
1 0
0 0
Tech News 2025, week 40
by Uzoma Ozurumba 30 Sep '25

30 Sep '25
Latest *tech news<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News>* from theWikimedia technical community. Please tell other users about these changes.Not all changes will affect you. Translations<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2025/40> areavailable.*Weekly highlight* - A major software upgrade has been made to Phabricator <https://phabricator.wikimedia.org/>. The update introduces performance improvements, a refreshed search interface, enhancements to Maniphest task search, updates to user profile pages and project workboards, new Herald automation features, as well as general text input, mobile experience improvements and more. [1] <https://phabricator.wikimedia.org/phame/post/view/321/iterative_improvement…>*Updates for editors* - The Community Tech team will release the new Community Wishlist extension on October 1, that will improve the way wishes will be submitted. The new extension will allow users to add tags to their wishes to better categorise them, and (in a future iteration) to filter them by status, tags and focus areas. It will also be possible to support individual wishes again, as requested by the community in many instances. The old system will be retired. There will be a brief period of downtime while the extension is deployed and wishes are migrated to the new system. You can read more about this in the latest update <https://meta.wikimedia.org/wiki/Special:MyLanguage/Community_Wishlist/Updat…>or you can consult the current documentation on MediaWiki <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:CommunityR…> . - As announced on Diff blog <https://diff.wikimedia.org/2025/09/02/better-detecting-bots-and-replacing-o…>, the production trial of the hCaptcha <https://www.mediawiki.org/wiki/Special:MyLanguage/Product_Safety_and_Integr…>service for bot detection has begun. The trial is currently using hCaptcha to protect account creation on Chinese, Persian, Portuguese, Indonesian, Japanese, and Turkish Wikipedias, where it will replace our existing CAPTCHA <https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:ConfirmEdit#Fan…>(FancyCaptcha). The goal with the trial is to better block bots while also improving usability and accessibility for users who encounter CAPTCHA challenges. - The CampaignEvents <https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:CampaignEvents>extension has been deployed <https://meta.wikimedia.org/wiki/Special:MyLanguage/CampaignEvents/Deploymen…>to Wikimedia Commons. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. On Commons, anyone who is a registered user can use it as an event participant. To use it as an organizer, someone needs to have the event organizer right <https://commons.wikimedia.org/wiki/Special:MyLanguage/Commons:Event_organiz…> . - Sub-referencing <https://meta.wikimedia.org/wiki/Special:MyLanguage/WMDE_Technical_Wishes/Su…>, a new feature to re-use references with different details has been released to German Wikipedia. You can test the feature <https://meta.wikimedia.org/wiki/Special:MyLanguage/WMDE_Technical_Wishes/Su…>on testwiki or on betawiki <https://en.wikipedia.beta.wmcloud.org/wiki/Sub-referencing> as well. Please share your thoughts on using templates in sub-references <https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Sub-referencing#…> or volunteer to become a pilot wiki <https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Sub-referencing#…> . - On wikis using the Mentorship <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Growth/Mentorship>system, communities can now opt experienced editors out of Mentorship through Special:CommunityConfiguration/Mentorship <https://meta.wikimedia.org/wiki/Special:CommunityConfiguration/Mentorship>. Within this setting, communities may define thresholds, based on edit count and account age, to decide when an editor is considered experienced enough to no longer receive Mentorship. [2] <https://phabricator.wikimedia.org/T403563> - The Editing Team and the Machine Learning Team are working on a new check for newcomers: Tone check <https://www.mediawiki.org/wiki/Special:MyLanguage/Edit_check/Tone_Check>. Using a prediction model, this check will encourage editors to improve the tone of their edits, using artificial intelligence. We invite volunteers to review the first version of the Tone language model for the following languages: Arabic, Czech, German, Hebrew, Indonesian, Dutch, Polish, Russian, Turkish, Chinese, Farsi, Italian, Norwegian, Romanian and Latvian. Users from these wikis interested in reviewing this model are invited to sign up atMediaWiki.org <https://www.mediawiki.org/wiki/Special:MyLanguage/Edit_check/Tone_Check/Mod…>. The deadline to sign up is on October 3, which will be the start date of the test. - The rollout of multiblocks <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Manage_blocks> had the side effect that non-active block logs may have been shown on Special:Contributions and on blocked users' user and user_talk pages. This issue will be fully resolved in a few days. As part of the fix, messages prefixed with sp-contributions-blocked-notice <https://meta.wikimedia.org/w/index.php?title=Special:Allmessages&prefix=sp-…>will be removed and replaced with those prefixed with blocked-notice-logextract <https://meta.wikimedia.org/w/index.php?title=Special:Allmessages&prefix=blo…>in a few weeks. Please help translate the new messages and update any local overrides if needed. - There was a bug with links added using visual editor if they included characters such as [ ] | after the fragment identifier (#). They were not encoded properly creating an incorrect link. This has been fixed. [3] <https://phabricator.wikimedia.org/T404823> - One new wiki has been created: a Wikiquote in Malay <https://www.wikidata.org/wiki/Q9237> (q:ms: <https://en.wikiquote.org/wiki/ms:>) [4] <https://phabricator.wikimedia.org/T404698> - [image: Recurrent item] View all 21 community-submitted tasks that were resolved last week <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Recently_resol…>. For example, the User Info Card <https://www.mediawiki.org/wiki/Special:MyLanguage/Product_Safety_and_Integr…>now displays currently active global lock/blocks. [5] <https://phabricator.wikimedia.org/T401128>*Updates for technical contributors* - Later this week, editors using Lua modules will be able to use the mw.title.newBatch <https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:Scribunto/Lua_r…>function to look up the existence of up to 25 pages at once, in a way that only increases the expensive function <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Parser_functions#E…>count once. - A new Unsupported Tools Working Group <https://meta.wikimedia.org/wiki/Special:MyLanguage/Product_and_Technology_A…>has been formed as part of ongoing efforts to collectively determine technical work priorities, similar to the Product & Technology Advisory Council <https://meta.wikimedia.org/wiki/Special:MyLanguage/Product_and_Technology_A…>(PTAC). The working group will help prioritize and review requests for support of unmaintained extensions, gadgets, bots, and tools. For the first cycle, the group will be prioritizing an unsupported Wikimedia Commons tool. - [image: Recurrent item] Detailed code updates later this week: MediaWiki <https://www.mediawiki.org/wiki/MediaWiki_1.45/wmf.21>*Tech news<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News> preparedby Tech News writers<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Writers> andposted by bot<https://meta.wikimedia.org/wiki/Special:MyLanguage/User:MediaWiki_message_d…>• Contribute<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News#contribute>• Translate<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2025/40> • Gethelp <https://meta.wikimedia.org/wiki/Tech> • Give feedback<https://meta.wikimedia.org/wiki/Talk:Tech/News> • Subscribe or unsubscribe<https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Tech_ambass…>.*-- Uzoma Ozurumba (She/her)Movement Communications Specialist (Product and Tech)meta.wikimedia.org/wiki/User:UOzurumba_(WMF)
1 0
0 0

29 Sep '25
Hello everyone,As part of the RESTBase Sunset effort, some endpoints are being phased outin favor of better, more stable alternatives or completely removed.The /page/talk <https://en.wikipedia.org/api/rest_v1/#/Talk%20pages>endpoint is now ready for deprecation. This endpoint is marked asexperimental and its usage has been exclusively by the Android and iOSapps whichteams signed off on the deprecation readiness<https://phabricator.wikimedia.org/T392491>. This endpoint has noalternatives.Next steps: because this is an experimental endpoint, we decided to applythe existing policy for REST endpoints<https://www.mediawiki.org/wiki/API_versioning#Experimental> and turn itoff as soon as possible while still respecting Android and iOS oldversions' deprecation timeline. Traffic to this endpoint can be blockedstarting Today, Sep 29th 2025 (09/29/2025) and code will be removed afterthat. Details about the deprecation can be found in this phabricator task,T401895 <https://phabricator.wikimedia.org/T401895>.Don't hesitate in getting in touch in case you have any questions orconcerns.Best regards,--Mateus SantosProduct Manager - MediaWiki Engineering GroupWikimedia Foundation
1 0
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp