Wikitech-l October 2024

wikitech-l@lists.wikimedia.org

43 participants
43 discussions

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

User style to reduce Gerritbot comments on Phabricator
by Bartosz Dziewoński 25 Mar '25

25 Mar '25

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

8 12

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

Empowering Businesses with Innovative Digital Solutions
by consultancyservices393＠gmail.com 15 Feb '25

15 Feb '25

MCS offers software consulting and development services, delivering digital transformation. Our services includes web application development, mobile application development, chatbot development, Data Science & AI Development Services, MVP Development, End-to-End IT Strategy & Consulting and implementation support, intuitive digital solutions, and leveraging the latest technologies. visit here: https://www.mayuraconsultancy.com

2 3

Proposal to improve cancellable promises in mw.Api [patch]
by Bartosz Dziewoński 13 Jan '25

13 Jan '25

Hi all, You're probably familiar with the mw.Api JavaScript class <https://doc.wikimedia.org/mediawiki-core/master/js/mw.Api.html> provided by MediaWiki, which can be used to make requests to our action API. promise = ( new mw.Api() ).get( /*...*/ ); You may also know that the promises it returns are enhanced with an .abort() method, which cancels the underlying HTTP request and rejects the promise. promise.abort(); The problem is that this method is only available on the original promise object. If you try to chain promises, it no longer works: promise.then( /*...*/ ).abort(); // Error: abort is not a function Copying this method to the chained promise is very cumbersome. I will spare you an example, but you can find it in the Phabricator task I filed for this problem: T346984 <https://phabricator.wikimedia.org/T346984>. It's also not possible to do if you use async/await, which we'll hopefully be able to use in MediaWiki code soon. The designers of the HTML5 Fetch API <https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API> came up with a different solution to the problem of cancelling HTTP requests: abort signals <https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#canc…>. The Fetch API is increasingly being used outside of the MediaWiki world, and so I would like to enhance our mw.Api to support the same approach. *Here's my proposal: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/959350* As you can tell by the six-digit patch number, I've had a hard time finding anyone else interested in this, so I'm sending out this call for reviewers. I hope there's someone out there with review rights who likes the idea as well :) You can read the documentation with examples of the new style here: https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortContro… The.abort() method is not being removed, and as a bonus, the patch includes improved documentation for that style of cancellable promises: https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortablePr… -- Bartosz Dziewoński

1 1

The future of RSA certificates and TLS 1.2 at Wikimedia
by Brett Cornwall 03 Dec '24

03 Dec '24

The Wikimedia Foundation uses HTTPS to protect users from eavesdropping and tampering of Wikimedia project pages [1]. As time passes, security protocols gain advancements while weaknesses hamper established protocols. WMF monitors such developments and adjusts ciphers/protocols to provide a secure and performant browsing experience. Wikimedia projects serve RSA and ECDSA certificates; RSA certificates will be removed soon. Wikimedia projects are to serve only ECDSA certificates going forward [2]. RSA certificate usage comprises a fraction of traffic (~0.1%). Additionally, RSA continues weakening in security and increases our cost/overhead of certificate issuance (We pay twice for certificates: Once for ECDSA and once for RSA). In the distant future, WMF also intends on deprecating TLS 1.2 in favor of TLS 1.3 [3]. TLS 1.3 provides security and performance improvements and already comprises the majority of Wikimedia project traffic (TLS 1.2 traffic accounts for less than 4 percent of traffic to Wikimedia sites). Note that this deprecation is not scheduled anytime soon! We merely want to start coordinating with community members and projects to begin the transition. This mail only serves as a preliminary announcement of intent to eventually deprecate TLS 1.2, not as an official deprecation warning. [1] https://wikitech.wikimedia.org/wiki/HTTPS [2] https://phabricator.wikimedia.org/T370837 [3] https://phabricator.wikimedia.org/T367821

1 3

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