Wikitech-l February 2024

wikitech-l@lists.wikimedia.org

29 participants
40 discussions

User style to reduce Gerritbot comments on Phabricator
by Bartosz Dziewoński 08 Jan '26

08 Jan '26

Do your eyes glaze over when trying to make sense of Phabricator tasks with a long and troubled history of patches? Do you struggle to find the real people in the sea of automated bot comments? I've made myself a user style to compact the Gerritbot comments on Phabricator. You might like it too: https://userstyles.world/style/13140/wikimedia-phabricator-reduce-gerritbot… (See screenshots and installation instructions there.) -- Bartosz Dziewoński

10 23

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

API issue
by ovskmendov＠proton.me 17 Apr '25

17 Apr '25

Whenever I access the API, I get "Wikimedia Error: Our servers are currently under maintenance or experiencing a technical problem." Sometimes if I wait a bit, I'll get a few good requests, but it will shortly go back to the previous message. My code was working just fine a few days ago and I didn't change anything. Sent with [Proton Mail](https://proton.me/) secure email.

7 12

Acquiring list of templates including external links
by Takashi OTA 17 Apr '25

17 Apr '25

Hoi, This is an inquiry from my friend in academia, researching about Wikipedia. He would like to know whether there's a way to acquire a list of templates including external links. Here are some examples including external links. https://ja.wikipedia.org/wiki/Template:JOI/doc https://ja.wikipedia.org/wiki/Template:Twitter/doc Such links are stored in externallinks.sql.gz, in an expanded form. When you want to check increase/decrease of linked domains in chronological order through edit history, you have to check pages-meta-history1.xml etc. In a such case, traditional links and links by templates are mixed, Therefore, the latter ones (links by templates) should be expanded to traditional link forms. Sorry if what I am saying does not make sense. Thanks in advance, --Takashi Ota [[U:Takot]]

13 24

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Phabricator upstream shutdown
by Brian Wolff 21 Mar '25

21 Mar '25

It sounds like phabricator upstream is going away: https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_op… Just curious, are we planning to continue using it long term or move to something else? -- Brian

10 12

[Google Season of Docs] Call for documentation projects and technical writers
by Alexandra Paskulin 27 Nov '24

27 Nov '24

Hi all, We’re excited to announce Wikimedia’s participation in Google Season of Docs! 🎉 For the first time since 2020, Wikimedia is applying for Google Season of Docs[1]: a program that provides grants to technical writers to work on documentation for open-source projects. This year, we’ll be selecting one Wikimedia documentation project and, if accepted by Google, hiring one technical writer to complete the project. For details about the program and how to apply, see the wiki page[2]. Here's how you can get involved: - [Until March 22] Propose a project, share feedback on a project, or volunteer to help support a project[3]. - [Until April 28] Apply as a technical writer. We highly encourage Wikimedians to apply! Even if you’re not a professional technical writer, we value experience working on wikis. Our goal is to use this program to improve MediaWiki.org and other Wikimedia technical documentation, supplementing the work done by volunteers and staff. We’re hoping to use this year’s edition as a model to expand the program to multiple projects in future years. Let's make this a successful season of documentation together! 📚 Best, - Alex and Onyinyechi [1] - https://developers.google.com/season-of-docs [2] - https://www.mediawiki.org/wiki/Season_of_Docs/2024 [3] - https://www.mediawiki.org/wiki/Season_of_Docs/2024#Volunteering_to_support_… -- Alex Paskulin Technical Writer Wikimedia Foundation

1 1

Changes to JavaScript documentation tools
by Alexandra Paskulin 12 Nov '24

12 Nov '24

Hi everyone, tl;dr The tools we use to document Wikimedia JavaScript code are changing. In the short term, you can read the complete MediaWiki core JavaScript docs using the 1.41 version[0] while we migrate to the new system[1]. If you use JavaScript documentation on doc.wikimedia.org, please share your feedback on wiki[2]. Wikimedia JavaScript codebases are switching from using JSDuck[3] to JSDoc[4] for documentation. Started in 2016, this migration is necessary because JSDuck is currently unmaintained and does not support the ES6 standard[5]. Several Wikimedia JavaScript codebases, including Vector and GlobalWatchlist, already use JSDoc, while several others, such as VisualEditor and MediaWiki core, still use JSDuck. The migration project consists of two parts: changing the codebases to support JSDoc and improving the usability of the JSDoc WMF theme. For more information, see phab:T138401[6]. == Migrating MediaWiki core to JSDoc == We are migrating MediaWiki core to JSDoc incrementally. While the migration is in progress, the master branch docs will be incomplete, containing only those modules that have been migrated. To read the old JSDuck docs, see the MediaWiki 1.41 docs[0]. To help with migration, choose a module from the list in phab:T352308[7], and follow the guide on phab:T138401[6] to translate the tags from JSDuck to JSDoc. == Migrating other codebases == You can find a list of codebases that use JSDuck on phab:T138401[6]. (Please add any that are missing.) To help migrate a codebase that uses JSDuck, follow the instructions to set up JSDoc[8], and use the guide in phab:T138401[6] to translate the tags from JSDuck to JSDoc. == Improving the JSDoc WMF theme == One of the biggest differences between JSDuck and JSDoc is the HTML interface for reading the docs. The WMF theme for JSDoc is not as full-featured as the JSDuck theme, but to support this migration, the Wikimedia Foundation Web, Design Systems, and Technical Documentation teams are working to prioritize and complete a set of improvements to the JSDoc theme, with the goal of releasing version 1 of jsdoc-wmf-theme in 2024. If you use JavaScript documentation on doc.wikimedia.org, please leave a comment on the JSDoc WMF theme talk page[2] and let us know how you use the docs and which features of the theme are the most important to you. Thank you for reading! Alex, Kamil, Jon, Roan, and Anne [0]: https://doc.wikimedia.org/mediawiki-core/REL1_41/js/ [1]: https://doc.wikimedia.org/mediawiki-core/master/js/ [2]: https://www.mediawiki.org/wiki/Talk:JSDoc_WMF_theme [3]: https://github.com/senchalabs/jsduck [4]: https://en.wikipedia.org/wiki/JSDoc [5] https://en.wikipedia.org/wiki/ECMAScript [6]: https://phabricator.wikimedia.org/T138401 [7]: https://phabricator.wikimedia.org/T352308 [8]: https://www.mediawiki.org/wiki/JSDoc -- Alex Paskulin Technical Writer Wikimedia Foundation

1 2

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

Collect telemetry (using WikimediaEvents) for a gadget
by psnbaotg 08 Jul '24

08 Jul '24

Hi there, I'm User:Diskdance, and recently I'm developing a default gadget for Chinese Wikipedia enhancing MediaWiki's variant handling logic, and under certain circumstances a prompt is shown at page load asking for a user's preferred variant. Consider it as a conditional Cookie notice, and its English screenshot can be found at https://commons.wikimedia.org/wiki/File:VariantAlly-En.png. Iknowthis can be very disruptive on UX, so I tend to be careful about its negative impact on page views. If the gadget can collect telemetry data about the prompt's display frequency and user interactions(using e.g. WikimediaEvents), I can know about its possible impact. Is this possible? It would be much appreciated if anybody could provide assistance. Best wishes,Diskdance

6 8

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

Research FAQ gets a facelift
by Dario Taraborelli 25 Jun '24

25 Jun '24

We just released a new version of Research:FAQ on Meta [1], significantly expanded and updated, to make our processes at WMF more transparent and to meet an explicit FDC request to clarify the role and responsibilities of individual teams involved in research across the organization. The previous version – written from the perspective of the (now inactive) Research:Committee, and mostly obsolete since the release of WMF's open access policy [2] – can still be found here [3]. Comments and bold edits to the new version of the document are welcome. For any question or concern, you can drop me a line or ping my username on-wiki. Thanks, Dario [1] https://meta.wikimedia.org/wiki/Research:FAQ [2] https://wikimediafoundation.org/wiki/Open_access_policy [3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953 *Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter <http://twitter.com/readermeter>

2 1

[Wikitech-I] Call for Projects and Mentors for Google Summer of Code 2024 and Outreachy Round 28 is OPEN!
by Onyinyechi Onifade 25 May '24

25 May '24

Hello everyone, Wikimedia is gearing up to apply as a mentoring organization for Google Summer of Code 2024 < https://www.mediawiki.org/wiki/Google_Summer_of_Code/2024>[1] and Outreachy Round 28 <https://www.mediawiki.org/wiki/Outreachy/Round_28> [2]. Currently, we're crafting a list of exciting project ideas for the application. If you have any suggestions for projects, whether coding or non-coding (design, documentation, translation, outreach, research), please share them by February 5th via this Phabricator task: < https://phabricator.wikimedia.org/T354734> [3]. Note that for non-coding projects eligible for Outreachy, slots are limited and will be allocated to mentors on a first-come, first-serve basis. Timeline In your role as a mentor, your involvement spans the application period for both programs, taking place from March to April. During this time, you'll guide candidates in making small contributions to your project and address any project-related queries they may have. As the application period concludes, you'll further intensify your collaboration with accepted candidates throughout the coding period, which extends from May to August. Your support and guidance are crucial to their success in the program. Guidelines for Crafting Project Proposals: - Follow this task description template when you propose a project in Phabricator: < https://phabricator.wikimedia.org/tag/outreach-programs-projects> [4]. You can also use this workboard to pick an idea if you don't have one already. Add #Google- Summer-of-Code (2024) or #Outreachy (Round 28) tag. - Project should require an experienced developer ~15 days and a newcomer ~3 months to complete. - Each project should have at least two mentors, including one with a technical background. - Ideally, the project has no tight deadlines, a moderate learning curve, and fewer dependencies on Wikimedia's core infrastructure. Projects addressing the needs of a language community are most welcome. * Learn more about the roles and responsibilities of Mentors for both programs:* - Outreachy: <https://www.mediawiki.org/wiki/Outreachy/Mentors> [5] - Google Summer of Code: < https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors> [6] Thank you, Links: [1] https://www.mediawiki.org/wiki/Google_Summer_of_Code/2024 [2] https://www.mediawiki.org/wiki/Outreachy/Round_28 [3] https://phabricator.wikimedia.org/T354734 [4] https://phabricator.wikimedia.org/tag/outreach-programs-projects [5] https://www.mediawiki.org/wiki/Outreachy/Mentors [6] https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors -- *Onyinyechi Onifade * Technical Community Program Manager Wikimedia Foundation <https://wikimediafoundation.org/>

14 15

[action requested] Technical Decision-Making Retrospective Survey
by Moriel Schottlender 23 Apr '24

23 Apr '24

Hello all, The Technical Decision-Making Forum Retrospective team <https://www.mediawiki.org/wiki/Technical_decision_making> invites you to complete a survey about Wikimedia's technical decision-making processes. While there will be more ways to participate, this is the first and most important step in our data collection. It aims to gather information about your experience, thoughts, and needs regarding the process of making technical decisions across the Wikimedia technical spaces. This survey will be used for gathering information about the process and the needs around technical decision-making that touches our production systems. You can find the survey link here: https://wikimediafoundation.limesurvey.net/885471?lang=en Who should take this survey? People who do technical work that relies on software maintained by the Wikimedia Foundation (WMF) or affiliates. If you contribute code to MediaWiki or extensions used by Wikimedia, or you maintain gadgets or tools that rely on WMF infrastructure, this survey is for you. What is the deadline? *August 7th, 2023 * What will the Retrospective team do with the information? The retrospective team will synthesize the collected data and publish an anonymized analysis that will help leadership make decisions about the future of the process. We will collect anonymized information that we will analyze in two main ways: - Sentiments based on demographic information: these will tell us whether there are different needs and desires from different groups of people. - General needs and perceptions about decision-making in our technical spaces: This will help us understand what kind of decisions happen in the spaces, who is involved, and how to adjust our processes accordingly. Is the survey the only way to participate? The survey is the most important way for us to gather information because it helps us gather input in a structured manner. But it will not be the only way you can share your thoughts with us - we will have more information soon about upcoming listening sessions where you can talk with us live. In the meantime, you are always welcome to leave feedback on the talk page: https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec… Where can I see more information? There are several places where you can find more information about the Technical Decision-Making Process Retrospective: - The original announcement about the retrospective from Tajh Taylor: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/… - The Technical Decision-Making Process general information page: https://www.mediawiki.org/wiki/Technical_decision_making - The Technical Decision-Making Process Retrospective on MediaWiki: https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision… - Phabricator ticket: https://phabricator.wikimedia.org/T333235 How to contact the retrospective core team: - Write to the core team mailing list: tdf-retro-2023(a)lists.wikimedia.org - The Technical Decision-Making Process Retrospective on MediaWiki talk page: https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec… Thank you, Moriel, on behalf of the TDMP Retro Core Group Core group: - Moriel Schottlender (chair) - Daniel Kinzler - Chris Danis - Kosta Harlan - Temilola Adeleye -- Moriel Schottlender (she/her <https://pronoun.is/she>) Principal Software Engineer Wikimedia Foundation https://wikimediafoundation.org/

3 6

Changes in schema of pagelinks tables
by Amir Sarabadani 15 Apr '24

15 Apr '24

(If you don’t work with pagelinks table, feel free to ignore this message) Hello, Here is an update and reminder on the previous announcement <https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…> regarding normalization of links tables that was sent around a year ago. As part of that work, soon the pl_namespace and pl_title columns of pagelinks table will be dropped and you will need to use pl_target_id joining with the linktarget table instead. This is basically identical to the templatelinks normalization that happened a year ago. Currently, MediaWiki writes to both data schemes of pagelinks for new rows in all wikis except English Wikipedia and Wikimedia Commons (we will start writing to these two wikis next week). We have started to backfill the data with the new schema but it will take weeks to finish in large wikis. So if you query this table directly or your tools do, You will need to update them accordingly. I will write a reminder before dropping the old columns once the data has been fully backfilled. You can keep track of the general long-term work in T300222 <https://phabricator.wikimedia.org/T300222> and the specific work for pagelinks in T299947 <https://phabricator.wikimedia.org/T299947>. You can also read more on the reasoning in T222224 <https://phabricator.wikimedia.org/T222224> or the previous announcement <https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…> . Thank you, -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation <https://wikimediafoundation.org/>

1 2

Reminders about Wikimedia Wishathon
by Srishti Sethi 14 Mar '24

14 Mar '24

Hello, We are now only three weeks away from the Wikimedia Wishathon! Exciting news - User:Lucas Werkmeister has signed up to host a piano concert during a social hour 🎉 Join us and contribute to the development of community wishes between March 15th and 17th! Participate in discussion sessions and work on user scripts, gadgets, extensions, tools and more! The full event schedule is available here: < https://meta.wikimedia.org/wiki/Event:WishathonMarch2024>. Explore the event wiki for project ideas and keep an eye out for non-technical tasks (documentation and design-related) that will soon be added to the Wishathon workboard: < https://phabricator.wikimedia.org/project/view/5906/>. Project breakouts will also be added to the schedule, where you can participate in wish development or explore innovative solutions as a user, developer, or designer. We are seeking volunteers to assist with a wide range of activities such as monitoring discussion channels during hacking hours, answering technical queries, and helping with session note-taking. Check out the Help desk schedule and add yourself to a slot where you are available and interested in providing assistance: < https://meta.wikimedia.org/wiki/Event:WishathonMarch2024/Help_desk>. If you have any questions about the Wishathon, reach out via Telegram: < https://t.me/wmhack>. Cheers, Srishti On behalf of the Wishathon organizing committee *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

1 2

MediaWiki Insights: February edition
by Birgit Müller 01 Mar '24

01 Mar '24

Hi All, welcome to the monthly MediaWiki Insights email! Like last time <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/January_2…>, we’re starting this email by celebrating volunteer contributors who got their first patch merged in MW core, WMF deployed extensions or services over the past month: A big thanks to GergesShamon and Agent Isai for their contributions! Welcome :-) Many thanks also to the reviewers - volunteers and staff - of patches by new contributors. Your support is invaluable for helping people contribute to MediaWiki effectively and make it a fun first experience! The focus of this edition of the monthly MW Insights email lies on our multi-year initiatives: Migration of MediaWiki from bare metal to Kubernetes <https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes> in Wikimedia Production, Parser Unification <https://www.mediawiki.org/wiki/Parsoid/Parser_Unification> and RESTBase deprecation <https://phabricator.wikimedia.org/project/profile/6289/>. These initiatives involve many people and projects, require orchestrated efforts and coordination, and will help us in many different ways. Another thing that these initiatives have in common is that we’re getting closer to being able to benefit from these efforts :-). Project Snapshots: Milestones reached on 3 multi-year projects MediaWiki on Kubernetes migration is 75% complete, completing migration of all internal traffic, all scheduled jobs and reaches 50% global traffic milestone! Often shortened as mw-on-k8s, MediaWiki on Kubernetes is a multi-year effort to move all of the MediaWiki deployments running on WMF production infrastructure to the new WikiKube platform. The migration is underway and very recently a new milestone was hit where the WikiKube platform now serves 50% of end user requests <https://phabricator.wikimedia.org/T290536>. At half mark, having more percentage of traffic on WikiKube, Service Operations is working with Release Engineering to make changes to monitoring tools to surface any issues during deployments to continue with further ramps. Also, almost the entirety of what is called internal traffic <https://phabricator.wikimedia.org/T333120>, that is traffic that is generated by applications running in the infrastructure and reaching out to MediaWiki for various purposes is migrated to WikiKube. A special mention should go to MediaWiki Jobs fully migrated just a week ago <https://phabricator.wikimedia.org/T349796>. Feel free to follow the higher umbrella task <https://phabricator.wikimedia.org/T290536> and/or MediaWiki_On_Kubernetes on Wikitech <https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes>. This migration will unleash the ability to deploy multiple versions of code simultaneously. Also, this will help enhance platform capabilities to build dockerized isolated environments for coding, testing and even production debugging. MediaWiki on Kubernetes will allow us to deprecate and eventually remove a lot of our in-house developed code. Another benefit is that we will be able to react to sudden traffic spikes, like newsworthy events better, as the flexing up and down is a matter of configuration change. This enables efficient placement of workloads, packing workloads in a more environmentally friendly way, increasing hardware utilization. It takes a village to get this far: A big thanks to the Service Operations team (Clément Goubert, Giuseppe Lavagetto, Alexandros Kosiaris, Kamila Součková, Hugh Nowlan, Effie Mouzeli, Reuven Lazarus, Jannis Mayboom and Kavitha Appakayala) for their leadership on this project, the Release Engineering team (specifically: Dan Duvall, Jeena Huneidi, Tyler Cipriani and Ahmon Dancy) for their work on Blubber <https://wikitech.wikimedia.org/wiki/Blubber>, the Deployment Pipeline <https://wikitech.wikimedia.org/wiki/Deployment_pipeline> and Scap <https://wikitech.wikimedia.org/wiki/Scap>, Dom Walden from Quality and Test Engineering for crafting and executing a plan to test the first deployment of MediaWiki on Kubernetes, and everyone else who has contributed in the one way or the other! <3 More milestones: We’re seeing the first lights at the end of the tunnel of another multi-year initiative: The *parser unification* <https://www.mediawiki.org/wiki/Parsoid/Parser_Unification>. One week ago, Parsoid Read Views was rolled out to first wikis: Parsoid is now the default read views renderer on the Foundations’ Office Wiki and Wikitech DiscussionTools. This early experimentation allows us to find issues in a limited space, which will help us evaluate readiness of the feature and increase our confidence for future rollouts <http://mediawiki.org/wiki/Parsoid/Parser_Unification/Confidence_Framework>. A huge thanks to Subbu Sastry, Mateus Santos, CScott, Isabelle Hubert-Pallatin, Arlo Breault, Shannon Bailey, Yiannis Giannelos and Sérgio Lopes for making this work! Many thanks also to Daniel Kinzler: His work on the RESTBase deprecation directly helped us get to this milestone :-) *RESTBase deprecation*: We have been continuously working on decoupling services from RESTBase, aiming for the modernisation and sustainability of Wikimedia products in our services platform. The MediaWiki Interfaces team finished up reimplementation of Reading Lists endpoints in MW REST API <https://phabricator.wikimedia.org/T348491> and are now confirming with affected callers <https://phabricator.wikimedia.org/T357478> that the new endpoints meet their needs before rerouting calls <https://phabricator.wikimedia.org/T348493> and retiring old code <https://phabricator.wikimedia.org/T348494>. The overall effort <https://phabricator.wikimedia.org/T336693> will not only move us forward on RESTBase retirement, but also reduce the total amount of code we have to maintain. Many thanks to Bill Pirkle, Atieno Njira, Wendy Quarshie, and Daniel Kinzler for making this work! We also fully turned off Parsoid cache storage in RESTBase - clients will get outputs direct from MediaWiki and the cache will be handled by ParserCache. Next, we will re-route clients directly to MediaWiki and fully remove Parsoid from RESTBase (T344944 <https://phabricator.wikimedia.org/T344944>). The Page Content Service (PCS) will also handle its own cache <https://phabricator.wikimedia.org/T348995> and we are ready to test the new capabilities in staging soon. Many thanks to Yiannis Giannelos and the Content Transform team and to Daniel Kinzler for his efforts and support on decoupling Parsoid from RESTBase! All of these multi-year initiatives help us increase sustainability and maintainability of the platform, streamline engineering and developer workflows, and unlock the path for new and improved platform capabilities and product opportunities. Outlook: Knowledge Platform in the annual plan 2024/2025 The Wikimedia Foundation has recently published the draft objectives by the Product & Technology department <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> for the next annual plan on Meta, alongside an introduction by Selena Deckelmann and a few questions that we’re exploring <https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2024-…>. Your input on these questions is very welcome! The draft objectives include “Knowledge Platform I” - centered around MediaWiki platform evolution and “Knowledge Platform II” - centered around developer/engineering services and workflows. The objectives show only the high-level direction for next year. The draft “key results” (currently work in progress) will give a better idea of what areas of work we’re thinking about. We’ll be publishing these in March and share the link + invitation for feedback with this list again. Thanks all for reading, Birgit -- Birgit Müller (she/her) Director of Product, MediaWiki and Developer Experiences Wikimedia Foundation <https://wikimediafoundation.org/>

2 1

[Train] 1.42.0-wmf.19 / wmf.20 status: blocked on T336504 (Transcluding Special:Prefixindex forces default skin), may require Monday rollback
by Brennen Bearnes 26 Feb '24

26 Feb '24

This week's 1.42.0-wmf.20 version of MediaWiki is blocked[0], and 1.42.0-wmf.19 may require a Monday rollback, which is a situation we hope to avoid. We can't proceed until the following issue is resolved: * T336504 - Transcluding Special:Prefixindex can force the default skin - https://phabricator.wikimedia.org/T336504 For context, see the Village pump discussion linked here: * https://phabricator.wikimedia.org/T336504#9572477 Once this issue is resolved, the train can proceed normally for the week. Thank you for any help! -- Your designated sacrificial train victims [0]. https://phabricator.wikimedia.org/T354438

1 0

Northward Datacentre Switchover (March 2024)
by effie mouzeli 26 Feb '24

26 Feb '24

Dear all, *"There is nothing permanent except change - Heraclitus"* On *Wednesday March 20th 2024,* the SRE team will run a planned datacentre switchover, moving all wikis from *codfw* to *eqiad*. This is an important periodic test of our tools and procedures, to ensure the wikis will continue to be available even in the event of major technical issues in our primary home. It also gives all our SRE and ops teams a chance to do maintenance and upgrades on systems in codfw that normally run 24 hours a day. The switchover process requires a brief read-only period for all Foundation-hosted wikis, which will start on *Wednesday March 20th 2024 @ 14:00 UTC*, and will last for just a few minutes while we execute the migration as efficiently as possible. All our public and private wikis will be continuously available for reading, as usual, but editing will be unavailable during the process. Users will see a notification of the upcoming maintenance, and anyone still editing will be asked to try again in a few minutes. CommRel will soon begin notifying communities of the read-only window. If you like, you can follow along on the day in the public *#wikimedia-operations* channel on IRC. To report any issues, you can reach us in *#wikimedia-sre* on IRC, or file a Phabricator ticket <https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=Data…>with the #datacenter-switchover tag; we'll be monitoring closely for reports of trouble during and after the switchover. The switchover and its preparation will be tracked under https://phabricator.wikimedia.org/T357547. On behalf of the SRE team, please excuse the disruption, and we would like to thank everyone in various departments who are involved in planning this work. If you have any questions, please reply directly to this email. Kind Regards, -effie

2 1

Etherpad maintenance 2024-02-26 09:00 - 10:00 UTC
by Jelto Wodstrcil 26 Feb '24

26 Feb '24

Hi all, we have to do *maintenance* on etherpad.wikimedia.org next *Monday, 2024-02-26** 09:00 UTC*. The maintenance involves the switch of the underlying hardware and a version upgrade. So the estimated downtime is around *60 minutes*. If you are working on a document currently please make a backup outside of Etherpad and do not use Etherpad during the maintenance window. I'll let you know when the maintenance is finished. You can find more information in https://phabricator.wikimedia.org/T316421. Greetings jelto

1 1

23 Feb '24

Hello all, The next language community meeting is coming up in a few weeks - *February 21st, 12:00 pm UTC*. If you're interested, you can sign up on this wiki page: < https://www.mediawiki.org/w/index.php?title=Wikimedia_Language_engineering/… >. This meeting is for individuals involved in creating content or managing technical aspects across different language communities. This will be a participant-driven meeting, where we collectively discuss specific technical issues related to language wikis and work together to find possible solutions. This could involve anything from fixing a broken template on the Kurdish wiki to brainstorming ideas for growing content on the Tulu Wiktionary, currently in the Wikimedia Incubator, or celebrating the creation of Fon Wikipedia, to using MinT for content translation. Feel free to add any *technical updates* related to your project or ideas for *problem-solving* discussion that you would like to share during the meeting to the notes document here: < https://etherpad.wikimedia.org/p/language-community-meeting-february-2024>. If you need interpretation support from English to another language, please let us know by sending an email to ssethi(a)wikimedia.org. Looking forward to your participation! Cheers, Jon, Mary & Srishti *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

2 4

APIi page generator namespace order
by Bináris 22 Feb '24

22 Feb '24

Hi, I query special pages through API (concretely Special:UnconnectedPages), and I noticed that main namespace articles are yielded first. It seems that pages are ordered by namespace numbers. Is it a guaranteed behaviour? (If so, I can break from the loop at te first page not in 0 namespace which would be nice.) -- Bináris

2 2

Parsoid Read Views is enabled for DiscussionTools in Wikitech
by Mateus Santos 22 Feb '24

22 Feb '24

Hello everyone, I am glad to inform you that as part of our initial experimentations with Parsoid Read Views, Parsoid is turned on as the default read views renderer in Wikitech for DiscussionTools. Here's the rationale <https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Confidence_Framew…> behind our confidence to roll-out this experimental feature and collect feedback. This is an opportunity to experiment the changes confidently before we start rolling out more wikis. If this disrupts your workflow, don’t worry you can still opt out through a user preference or turn Parsoid off on the page you’re navigating in the Tools submenu. To report bugs and issues, please look at our known issues <https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Known_Issues> documentation and if you found a new bug please create a phab ticket and tag the Content Transform Team in Phabricator <https://phabricator.wikimedia.org/project/view/5846> or send us a message in our slack channel #content-transform-team. More relevant info about our roll-out strategy can be found on this wiki page <https://m.mediawiki.org/wiki/Parsoid/Parser_Unification/Confidence_Framework> . Best regards, Mateus

1 0

About problematic Chinese language variant support on mobile apps
by psnbaotg 22 Feb '24

22 Feb '24

Hi all, Today when playing around Wikipedia iOS app I'm surprised to find out that the Chinese language variant support is still somewhat broken. There is no zh-cn variant available, only zh-hans (displayed as "Simplified Chinese"). I haven't touched the Android app for a while, but in my last review it mistakenly includes zh-hans and zh-hant variants. As I mentioned in https://phabricator.wikimedia.org/T305319, the correct list of variants the app should include should be: zh-cn, zh-sg, zh-my, zh-tw, zh-mo, zh-hk. Other zh variants have incomplete conversion, thus should be excluded. I hope somebody at the relevant team could reach out to me and discuss possible solutions. If you don't understand the reason to do this I can give a detailed explanation. I believe this task should not be triaged as "Low" because it has negative impacts on Chinese readers. Best regards, Diskdance

2 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2024