Wikitech-l January 2024

wikitech-l@lists.wikimedia.org

36 participants
41 discussions

Gallery image size defaults
by Peter.Ingraham＠gmail.com 10 Jan '24

10 Jan '24

Hello all, I'd like to talk about the default gallery settings, and the technical feasibility of updating them. By default in MediaWiki, they are 120 pixel height, 120 pixel width: * https://github.com/wikimedia/mediawiki/blob/master/includes/SetupDynamicCon… * https://www.mediawiki.org/wiki/Manual:$wgGalleryOptions This is, in retrospect, too small. It's fine for something like a gallery of simple images that display well at low resolutions like flags, but it's woefully undersized for the far more common case of detailed artwork, photographs, screenshots, etc. Many other user-facing websites have adopted to show larger pictures when possible, backed by consumer studies. Other wikis often increase the default gallery size. 200x200 would be a better default (or possibly even larger!). What would be required to merge a change of this? Ideally for all WMF projects on MediaWiki, or all Wikipedias, but the English language edition of Wikipedia would also work. There's an old Phabricator ticket filed in 2012 (!) asking for permission to increase the Hebrew Wikipedia default gallery size: * https://phabricator.wikimedia.org/T43712 And judging by the file currently used, it seems Swedish Wikipedia already has a larger size: * https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/… However, I was warned that it's possible the default image thumbnailer might need to be updated to create thumbnails at whatever the new default is. There's a 2013 comment in the above Phabricator thread saying that different language editions shouldn't use different thumbnail sizes to prevent needlessly creating tons of files. That said, this ship has already sailed - tons of galleries already custom-set larger sizes, and Module:Gallery on English Wikipedia even tries to use 180x180 as the default for when people use a template to create a Gallery. More generally, what are the sizes of thumbnails already created by default? If there's truly a desire to not create a new default image size, fine, let's set the gallery default to some value that's already being created (say, 220x220?). That won't cause any additional load, then. It might even reduce load, since fewer editors will feel the need to adjust gallery sizes upward manually to random bespoke sizes. I'd like to get this change eventually merged in. If there's anything else stopping just changing the above setting to a larger default, or stakeholders who'd need to be convinced, would be happy to hear feedback. (Context: We had a hacking night at the NYC Wikimedia chapter, and this list was recommended as a good place to take the temperature of this proposal. See https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC/Hacking_Night_January_20… .) -SnowFire

2 2

Reusing references: Can we look over your shoulder?
by Thereza Mengs 10 Jan '24

10 Jan '24

Apologies for writing in English. The Technical Wishes team at Wikimedia Deutschland is planning to make reusing references easier <https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Reusing_references>. For our research, we are looking for wiki contributors willing to show us how they are interacting with references. - The format will be a 1-hour video call, where you would share your screen. More information can be found here <https://wikimedia.sslsurvey.de/User-research-into-Reusing-References-Sign-u…>: - Interviews can be conducted in English, German or Dutch. - Compensation is available <https://www.mediawiki.org/wiki/WMDE_Engineering/Participate_in_UX_Activitie…>: - Sessions will be held in January and February. - Sign up if you are interested <https://wikimedia.sslsurvey.de/User-research-into-Reusing-References-Sign-u…>: - Please note that we probably won’t be able to have sessions with everyone who is interested. Our UX researcher will try to create a good balance of wiki contributors, e.g. in terms of wiki experience, tech experience, editing preferences, gender, disability and more. If you’re a fit, she will reach out to you to schedule an appointment. We’re looking forward to seeing you, Thereza for Wikimedia Deutschland’s Technical Wishes -- Thereza Mengs Werkstudentin Community-Kommunikation Technische Wünsche Wikimedia Deutschland e. V. | Tempelhofer Ufer 23–24 | 10963 Berlin Tel. +49 (0)30-577 11 62-0https://wikimedia.de Bleiben Sie auf dem neuesten Stand! Aktuelle Nachrichten und spannende Geschichten rund um Wikimedia, Wikipedia und Freies Wissen im Newsletter: Zur Anmeldung <https://www.wikimedia.de/newsletter/>. Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!https://spenden.wikimedia.de Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. Geschäftsführende Vorstände: Franziska Heine, Dr. Christian Humborg.

1 0

AI phabricator profile
by Martin Domdey 09 Jan '24

09 Jan '24

Hi, how is it possible, that an AI knows about my Phabricator real name user profile? Have AI access to WMF phabricator user profiles? Is this a security issue? Kind regards Doc Taxon ...

3 3

"Known languages" or similar?
by Strainu 08 Jan '24

08 Jan '24

Hi folks, I'm trying to add a "translate" link to [[:ro:Template:Ill-wd]] (which indicates a subject by it's wikidata id) and I need to determine the original language. Is there a way to determine if the current user prefers/knows some languages except the wiki's own language? I know I can use the interface language, but for the vast majority of users that's identical to the content language. I vaguely remember that Content Translation asked be at some point about what languages it should use to provide suggestions, but I can't find that setting now. Does it still exist and is it available somehow from outside CX? Are there any other data sources I can use (and which don't ruin caching, either)? Thanks, Strainu

3 2

{REMINDER} Register and Apply for Scholarships for the 2024 Wikimedia Hackathon!
by Onyinyechi Onifade 05 Jan '24

05 Jan '24

Hey Everyone, We hope this message finds you in great spirits and excitement for the upcoming Hackathon! 🚀 Time is ticking, and we don't want you to miss out on this incredible opportunity to be part of a collaborative and innovative event. To-Do: 1. *Register: *Secure your spot by completing the registration form [Hackathon Registration Link <https://pretix.eu/wikimedia/wmhackathon2024/>]. Remember the registration portal will remain accessible until we hit our venue's capacity, which is approximately set at 220 participants. 2. *Scholarship Application:*We are committed to nurturing a diverse and inclusive community. As part of this commitment, we offer scholarships that cover travel and accommodation expenses for a selected group of technical contributors. [To apply: Scholarship Application Link <https://pretix.eu/wikimedia/wmhackathon2024/>]. Remember, the deadline for scholarship applications is *January 5th, 2024*. If you have any questions or need assistance, our team is here to help. Feel free to reach out to hackathon(a)wikimedia.org for support. Best regards, -- *Onyinyechi Onifade * Technical Community Program Manager Wikimedia Foundation <https://wikimediafoundation.org/>

3 3

Wikimedia developer satisfaction survey, December 2023
by Tyler Cipriani 05 Jan '24

05 Jan '24

Hello! Please take the December 2023 Developer Satisfaction Survey! Link: <https://wikimediafoundation.limesurvey.net/484133> https://wikimediafoundation.limesurvey.net/796964 The survey is open until Fri, 5 January 2024—four weeks from today. ____ This survey is for members of the Wikimedia developer community and covers the following topics: - Wikimedia Cloud Services - Development and testing environments - Phabricator - Code review - Continuous Integration - Deployment - Code quality - Technical documentation - Developer research needs Please take the survey if you play a role in developing software for the Wikimedia ecosystem and would like to share your opinions on any of the topics listed above. We’re soliciting your feedback to: - Measure developer satisfaction, and - determine where to invest resources in the future We will anonymize, explore, and report the data we gather on mediawiki.org. View previous years' survey results: https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey Privacy statement: This survey will be conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data-handling, see the privacy statement. <https://foundation.wikimedia.org/wiki/Legal:December_2023_Developer_Satisfa…> Thank you! Tyler Cipriani (he/him) Engineering Manager, Release Engineering Wikimedia Foundation

1 1

[Train] 1.42.0-wmf.12 status update
by Dan Duvall 04 Jan '24

04 Jan '24

The 1.42.0-wmf.12 version of MediaWiki is blocked[0]. The new version is deployed to testwikis[1], but can proceed no further until these issues are resolved: * UniversalLanguageSelector compact links and @wikimedia/codex loads [...] ** https://phabricator.wikimedia.org/T353850 * Expected MediaWiki\Block\AbstractBlock to belong to the local wiki, but [...] ** https://phabricator.wikimedia.org/T354298 Once these issues are resolved train can resume. If these issues are resolved on a Friday the train will resume Monday. Thank you for your help resolving these issues! -- Your humble train toiler [0]. https://phabricator.wikimedia.org/T350088 [1]. <https://versions.toolforge.org/> -- Dan Duvall Staff Software Engineer, Release Engineering Wikimedia Foundation <http://wikimediafoundation.org>

1 1

MediaWiki Insights - Fourth Monthly Email
by Birgit Müller 04 Jan '24

04 Jan '24

Hi All, Welcome to the monthly MediaWiki Insights email! Enable more people to know MediaWiki and contribute effectively In the last MW insights email <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/October_2…> we shared more about our approach to helping people contribute effectively to MediaWiki <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>. A few interesting data points: The number of contributors to MediaWiki core who have more than > 5 patches continued to grow: We just hit for the first time the goal of 20% since the start of the Foundation’s fiscal year in July, compared to the July-November time period last year. This is exciting to see - now it’s about keeping the momentum and continuing on that path. Many thanks to all the people who have contributed to MediaWiki core! The average and median time to first review for patches in MediaWiki core decreased significantly in the period July 1st to Nov 30 compared to the same time period one year earlier. - Average time to first review dropped from previously 16.5 days to 4.5 days - Median time to first review dropped from previously 1.2 days to 0.6 days Many thanks to all the code reviewers of MediaWiki core patches! Keep in mind that this data is only one data point. There are many factors that play into the experience of contributors; a helpful comment may be more relevant than a fast +1/-1, etc. Over the past weeks, we have been spending some time with planning initiatives to further support people in onboarding and contributing to MediaWiki: - We are preparing for a WMF internal MediaWiki code jam in December to try out a few things and focus specifically on the needs of teams. - One thing we wanted to test in practice at the code jam is the “MediaWiki Quick Install <https://phabricator.wikimedia.org/T347347>” guide. This has been a collaboration between the Tech Docs team and the MediaWiki Platform team - you can find the latest version of this experiment here: https://www.mediawiki.org/wiki/Local_development_quickstart - We discussed a possible focus project in the next quarter on improving first time MediaWiki (core) contributors’ experience. We’re exploring a few simple, small ideas that we could implement/try out in the next quarter (ticket follows!). Project snapshot: Analysis of MediaWiki execution timings, fixing issues with logging in on Mobile, progress on RESTBase deprecation and more! Performance: Piotr and Timo conducted an analysis of MediaWiki execution timings <https://phabricator.wikimedia.org/T350593> and identified areas for improvement. One of the fixes promises a 50ms improvement <https://phabricator.wikimedia.org/T351807>! Timo and Derick worked on bagOStuff improvements <https://phabricator.wikimedia.org/T336004> (cache layer), shipped on MW-1.42. This work aims to lower the barriers for contributors by making interfaces leaner and more intuitive and is reducing storage access cost from 10ms to ~1 ms. Thank you for your work! More highlights: MediaWikiIntegrationTestCase now automatically tracks what database tables get touched during the integration test, removing the need for developers to keep track (T342301 <https://phabricator.wikimedia.org/T342301>). Many thanks to Daimona and others for their work on this! Work towards PHP 8.2 support continues, with one helpful outcome being a new DynamicPropertyTestHelper feature (T326466 <https://phabricator.wikimedia.org/T326466>). Many thanks to TK-999 and all reviewers! Gergö worked on solving a variety of problems with logging in on mobile (see https://phabricator.wikimedia.org/T257852#9347008 and below). Many thanks to Gergö and everyone who provided support! RESTBase sunset: Wikifeeds now calls the Parsoid endpoint in MediaWiki core rather than RESTBase. Many thanks to Yiannis and Daniel for their hard work on making this happen! Cxserver is preparing a deployment to the same soon <https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/977983/> (thank you, Language team!). Upcoming: There is an OutputTransform <https://www.mediawiki.org/wiki/Parsoid/OutputTransform> pipeline that is being introduced to replace ParserOutput::getText(). This pipeline initially targets content that comes from the ParserCache before it is rendered (as a 1:1 getText() equivalent ). The team is likely going to introduce another layer of cacheability of this output so that we can store richer canonical Parsoid content and use this pipeline to transform it for final rendering. Many thanks to Isabelle, CScott and Daniel for this work in progress (Gerrit:967449 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/967449>)! As one puzzle piece of our product research efforts and platform design explorations, Moriel and others have been working on mapping high level essential user workflows such as edit and patrol against platform components to explore workflow patterns and potential architectural opportunities in the platform. One outcome of this is going to be to describe the key challenges when trying to model our system. Many thanks to Moriel for leading on this work, and Daniel, Timo, Subbu, James, Cindy, Emanuele and Amir S for their support, great questions and ideas! Up next: Presentations at Semantic MediaWikiCon Semantic MediaWikiCon <https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023#Program> is coming up, virtual and in person from Dec 11-13. We shared about the updates to the rdbms library in the last MW Insights email - if you want to learn more about this work, check out Amir’s presentation at Semantic MediaWikiCon <https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Major_changes_on_i…>! Subbu and C.Scott are also going to give their yearly update on the parser unification work <https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Updates_from_the_W…>, Chris will be talking about Codex <https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Codex,_the_Design_…>, and Stef about automated testing for complex MediaWiki topologies <https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Automated_Testing_…>. Since the theme of this edition is MediaWiki in the age of AI, Mike will be presenting on the recent experiences with the experimental Wikipedia ChatGPT plugin <https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/The_Wikipedia_Chat…>. Keynote speaker of this years’ Semantic MediaWikiCon is Markus Krötsch <https://www.korrekt.org/page/Short_biography>. That’s the last insights email for 2023. The deployment train pauses for the end of the year break, and so does the monthly MW Insights email! We’ll be following up with a double-edition in January. Thanks all for reading, Birgit -- Birgit Müller (she/her) Director of Product, MediaWiki and Developer Experiences Wikimedia Foundation <https://wikimediafoundation.org/>

3 3

January 2024 - Technical Community Newsletter!
by Onyinyechi Onifade 04 Jan '24

04 Jan '24

Hello Tech Enthusiasts, *Welcome to 2024 🎉* and the 1st edition of the Wikimedia Technical Community Newsletter! 🥳We're excited to bring you a roundup of highlights, news, and information of interest from and about the Wikimedia Technical Community. Read the full January'24 newsletter edition here: 🔗mediawiki.org/wiki/Technical_Community_Newsletter/2024/January <https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2024/January> Here’s a sneak peek of what to expect from this newsletter edition 📢 Action Items - Take the December 2023 Developer Satisfaction Survey <https://wikimediafoundation.limesurvey.net/796964> before the deadline on January 5th 2024. - Scholarship applications for Wikimedia Hackathon 2024 are open until Friday, January 5th, 2024. Send in your applications <https://pretix.eu/wikimedia/wmhackathon2024/> before the deadline! 🚀 Project Spotlights: Get inspired by the latest project spotlights, showcasing innovative developments, successful collaborations, and noteworthy achievements within our technical community. Find out how these projects are shaping the future of our community. The Wikimedia Technical Community is large and diverse - it's hard to capture everything. We would love to hear your ideas. Have a topic you'd like us to cover or a story to share? Ideas for future newsletter editions? Please add your suggestion to the talk page <https://www.mediawiki.org/wiki/Talk:Technical_Community_Newsletter>. We'd love to hear from you! If you'd like to keep up with updates and information, subscribe to the Technical Community Newsletter: https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter Until the next edition, -- *Onyinyechi Onifade * Technical Community Program Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Some Phabricator and Gerrit 2023 statistics
by Andre Klapper 02 Jan '24

02 Jan '24

Hi everyone, Sharing some Phabricator and Gerrit statistics from the past Gregorian calendar year 2023. Big thanks to all Wikimedia technical contributors! === Phabricator 2023 === * 28095 tasks got created. * 26988 tasks got closed. * 3721 people were active in Phabricator. * 2176 people created tasks. * 868 people closed tasks. * The 20 accounts who created the most tasks: phaultfinder 869 <redacted spammer> 403 Jdlrobson 349 Reedy 245 RobH 244 awight 237 Maintenance_bot 219 dcaro 212 Jdforrester-WMF 210 Umherirrender 206 kai.nissen 202 kostajh 199 komla 195 ppelberg 192 rook 190 matmarex 188 MoritzMuehlenhoff 188 taavi 179 Dreamy_Jazz 177 Aklapper 177 * The 20 accounts who closed the most tasks: Aklapper 1045 taavi 998 matmarex 708 JArguello-WMF 505 Jdlrobson 494 XenoRyet 454 Etonkovidova 447 Jdforrester-WMF 425 Umherirrender 405 Pppery 374 Gehel 275 rook 272 Eileenmcnaughton 264 kai.nissen 264 Peachey88 258 aborrero 250 Ladsgroup 249 Reedy 247 Yaron_Koren 243 Jclark-ctr 239 === Gerrit 2023 === * 52815 changesets got created. [1] * 102225 code reviews took place. [2] * 577 people created patches. [3] * The 20 accounts who submitted the most changesets: [4] Umherirrender 2479 James Forrester 2057 Robert Vogel 1429 John Bond 1232 Moritz Muehlenhoff 1176 Taavi Väänänen 1001 Hslater 942 Bartosz Dziewoński 877 Marostegui 876 Sam Reed 834 Thiemo Mättig 830 Jon Robson 795 Timo Tijhof 772 Daniel Vogel 767 Ed Sanders 715 Daimona Eaytoy 708 Luca Toscano 694 Dejan Savuljesku 680 Eileen McNaughton 663 Amir Sarabadani 626 * The 20 accounts who reviewed the most patchsets: [5] John Bond 4622 Robert Vogel 3823 Moritz Muehlenhoff 3593 James Forrester 3556 DannyS712 2366 Nikerabbit 2231 Luca Toscano 2100 Daniel Vogel 2094 Marostegui 2069 Umherirrender 1990 Filippo Giunchedi 1862 Taavi Väänänen 1657 Daniel Zahn 1596 Bartosz Dziewoński 1589 Abijeet Patro 1559 Jon Robson 1552 Timo Tijhof 1533 Andrew Bogott 1504 Ben Tullis 1451 Janis Meybohm 1417 If you find a bug in these numbers, please see https://www.mediawiki.org/wiki/Community_metrics Cheers, andre [1] See "Gerrit 🡒 Changesets" on "Gerrit 🡒 Overview": https://wikimedia.biterg.io/goto/75c0ad9294bff8a7fe4a0c2a1c7cee62 [2] See "Total Changesets and Approvals 🡒 Approvals" on "Gerrit 🡒 Approvals": https://wikimedia.biterg.io/goto/d247957d88fd22293adc8e53901aa375 [3] See "Gerrit 🡒 Changeset Submitters" on "Gerrit 🡒 Overview": https://wikimedia.biterg.io/goto/75c0ad9294bff8a7fe4a0c2a1c7cee62 [4] See "Submitters" on "Gerrit 🡒 Overview": https://wikimedia.biterg.io/goto/75c0ad9294bff8a7fe4a0c2a1c7cee62 [5] See "Approvals by Reviewer" on "Gerrit 🡒 Approvals": https://wikimedia.biterg.io/goto/d247957d88fd22293adc8e53901aa375 -- Andre Klapper (he/him) | Bugwrangler https://blogs.gnome.org/aklapper/

1 0

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 January 2024