Wikitech-l October 2024

43 participants
39 discussions

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

Article source code style guide
by Bináris 03 Dec '24

03 Dec '24

Hi, is there anywhere a $subject? My first question is: is it better to leave an empty line under section titles or not? I would like to see pros and cons. Is there a consensus for preferred way? (I think source code style guides are primarily within the scope of programmers and not in that of users without programming experience, that's why I ask here.) -- Bináris

4 6

Parsoid Read Views roll out on Bengali, Hindi, Pushto, and Turkish Wikivoyage this week
by C. Scott Ananian 28 Nov '24

28 Nov '24

Hello everyone, I am glad to inform you that as part of our continued rollout of Parsoid Read Views, Parsoid will be turned on this week as the default read views renderer on Bengali, Hindi, Pushto, and Turkish Wikivoyage. Here's the rationale <https://www.mediawiki.org/wiki/Parsoid/Parser%20Unification/Confidence%20Fr…> behind our confidence to roll-out this experimental feature and collect feedback. This is an opportunity for continued experimentation as we increase the number of wikis using Parsoid for read views. 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, as described at the Extension:ParserMigration <https://www.mediawiki.org/wiki/Help:Extension:ParserMigration> page. To report bugs and issues, please look at our known issues <https://www.mediawiki.org/wiki/Special:MyLanguage/Parsoid/Parser%20Unificat…> 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>. There is more information about our roll-out strategy <https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Confidence_Framew…> available. Best regards, C. Scott Ananian <https://meta.wikimedia.org/wiki/User:CAnanian_(WMF)>, for the Content Transform Team >

2 5

[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 13 Nov '24

13 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

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