Wikitech-l

wikitech-l@lists.wikimedia.org

26 participants
23119 discussions

🚀 TK-999 receives Web Perf Hero award!
by Derick Alangi 17 Jan '24

17 Jan '24

Hi, I'm happy to share that the next Web Perf Hero award (for 2023 Q4) goes to TK-999, in recognition of their contributions, which made a huge positive impact on the performance of Wikimedia software. TK-999 worked on improving MediaWiki’s autoloading mechanism < https://gerrit.wikimedia.org/r/c/853972> ( https://phabricator.wikimedia.org/T274041) specifically for classes which have been namespaced, by including them in the classmap. This means our autoloader will not spend significant amounts of time searching for files in directories, but rather just do a direct lookup. This approach is particularly optimized for speed and as a result, Wikipedia’s backend response time gained a 20% increase in the portion of requests that complete within 50ms. This award is given once a quarter, and manifests as a Phabricator badge. More information and past recipients: https://wikitech.wikimedia.org/wiki/Web_Perf_Hero_award Phabricator badge: https://phabricator.wikimedia.org/badges/view/17/ -- Derick Alangi, on behalf of the MediaWiki Platform Team

3 3

Codex code splitting: ResourceLoader now supports loading individual Codex components
by Roan Kattouw 16 Jan '24

16 Jan '24

Hello everyone, The Design Systems Team is pleased to announce that ResourceLoader now supports basic code splitting for Codex <https://www.mediawiki.org/wiki/Codex> components. The way this works is similar to how Codex icons already work: you list the components you need in your ResourceLoader module definition, and only the components you need will be bundled. This should be helpful for performance, reducing the amount of code that is loaded by loading only the components your feature needs, not the entire library. Most new and existing uses of Codex should be able to use this feature. If you maintain code that uses Codex, we recommend trying this out! There's documentation for how to use this feature on the Codex page on mediawiki.org <https://www.mediawiki.org/wiki/Codex#Requiring_Codex_components_in_MediaWik…>, and you can also look at the CodexExample extension <https://gitlab.wikimedia.org/repos/design-systems/CodexExample> for a more complete example of how to use this feature. If you have any questions, or run into any issues trying to use this feature, we're here to help, feel free to reply to this email or post on the Codex talk page on mediawiki.org <https://www.mediawiki.org/wiki/Talk:Codex>. So far we have only implemented the most basic iteration of code splitting. We plan on building some more advanced features to help with deduplication of components as well. For more details about our plans, see the epic task <https://phabricator.wikimedia.org/T349423> on Phabricator. Roan Kattouw Software engineer on the Design Systems Team at the Wikimedia Foundation

1 0

phabricator.wikimedia.org downtime, Saturday 2024-01-20 @ 12:00 PST / 20:00 UTC
by Brennen Bearnes 16 Jan '24

16 Jan '24

Hi all, We'll be upgrading[0] phabricator.wikimedia.org this coming Saturday, starting at noon PST. This involves re-imaging a machine, so some downtime is expected, although we'll do our best to keep it at a minimum. As usual, operations will be conducted on libera.chat's #wikimedia-operations. [0]. https://phabricator.wikimedia.org/T334519 -- Brennen Bearnes Release Engineering Wikimedia Foundation

1 0

Suggestions to better maintain WMF portal pages
by psnbaotg 12 Jan '24

12 Jan '24

As some of you may know, the Wikimedia portal pages (https://github.com/wikimedia/wikimedia-portals) are virtually unmaintained, rely on unmaintained external tools, and use old-school coding styles (like concatenating JavaScript files). I feel like we'd better give it a complete overhaul (https://phabricator.wikimedia.org/T311361). In my humble opinion, the best toolkit replacement I can think of is using Vue and Vite, with some kind of static site generation (SSG) tools. Vue and Vite are both used by Codex, and allow us to write code like we are in 2024. What do you think of this? Any input is welcome. Sincerely, Diskdance

1 0

API issue
by ovskmendov＠proton.me 10 Jan '24

10 Jan '24

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.

6 11

Talk to the Search Platform / Query Service Team—January 10, 2024
by Guillaume Lederrey 10 Jan '24

10 Jan '24

Hello all! The Search Platform Team usually holds an open meeting on the first Wednesday of each month. Come talk to us about anything related to Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query Service (WCQS), etc.! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, January 10, 2024 Time: 16:00-17: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=8118110806927 Have fun and see you soon! Guillaume -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

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

Jump to page:

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