We have planned the last quarter of the Western calendar year (or, as we call it internally, Q2 of FY 2024/25), and as with the last few times, we are making our plan public. This time, we have even finished our planning before the quarter starts (yay!). It is a “short” quarter (due to a planned team offsite and the end of year holidays), and yet we've picked up a lot of work. Here’s a quick overview:

• Enable one Wikifunctions use case in one language Wikipedia: Just two weeks ago, we announced that we aim to have our first integration with Wikipedia on the Dagbani Wikipedia. We aim to develop everything needed for that integration this quarter, and to likely deploy it very early next year (i.e., January 2025).
• Wikipedia integration usability improvements: We will continue our research, design and user test usability enhancements to make the integration of Wikifunctions into Wikipedia easier. The implementation of these design improvements will happen afterwards.
• Iterate the Wikidata integration, and plan its and the Type system's evolution: We are very close towards the first integration of Wikidata into Wikifunctions. The next quarter will see us extend that integration to cover more parts of the Wikidata data model, and to evolve the Wikifunctions type system to work with that.
• Wikifunctions services alert monitoring: We want to be automatically notified when the Wikifunctions services are having issues.
• Service platform improvements: Our services are built on top of an outdated "template" of how to write a back-end service, originally created a decade ago before many changes in how Wikimedia manages them. We want to modernise our services, replacing the base platform with a simpler, faster framework. We also will explore rewriting the evaluator in a different language better suited to process management.
• On-wiki tooling to improve content and help editors onboard: We plan to create a set of related special pages to support the Wikifunctions community with maintenance, like finding proposed Implementations that need to be connected, or Functions that don't have any labels in a given language like French or Igbo.
• Testing Wikifunctions Services with Catalyst: Catalyst is the Wikimedia Foundation’s platform to support development through Continuous Integration and testing. We want to integrate the Wikifunctions backend services.
• Improve performance of the PHP layer: We want to give the MediaWiki layer a proper audit. For example, we know that we are validating objects more often than needed. The goal is to cut unnecessary work and improve performance.
• Make Phabricator more useful for the team: Phabricator is our main task and bug management system, but it needs some work to get a better handling of the many tasks on our board so that we are focussed on working on the right things at the right time.
• Establish team chores practice: As a team, we want to adopt practices to help us improve reliability of the site and our responsiveness to issues and questioned that you raise on the site.

We are looking forward to these developments, and hope you share in our excitement about the upcoming few months.

The Celtic Knot conference 2024 started yesterday in Waterford City, Ireland. On Friday, September 27, 2024, our own Genoveva Galarza Heredero will be presenting about Abstract Wikipedia at 11:30 local time / 10:30 UTC. You can attend the talk in person or online, and the talk will also be recorded.

Abstract: The availability of knowledge across different language editions of Wikipedia is far from equal. In this presentation, we will discuss Wikifunctions, a new initiative by the Wikimedia Foundation that empowers users to collaboratively build and maintain a shared library of code functions to enhance Wikimedia projects. Following this, we will introduce Abstract Wikipedia and explore how it utilizes Natural Language Generation functions maintained in Wikifunctions, combined with structured data from Wikidata, to create abstract representations of Wikipedia articles. These abstract articles can then be converted into natural language, helping to bridge the gap between languages on Wikipedia.

Here's an update for the last two weeks' work on technical matters.

Our main work was, as discussed last week, focused on the performance issues many of you encountered (T374241 and others). We worked around the issue with an on-wiki edit on Thursday, 19 September. Going out this week is a fix for the infinite-recursion crasher we identified as the immediate cause, but there is more work to come in this area.

This week, as part of the Quarterly work to support using Wikidata Lexemes and other entities in Wikifunctions calls, we have landed the custom selector for Wikidata Lexemes (T373589). We look forward to announcing more on this soon, including creating on-wiki all of the various new Types (T370341, T370343, T370344, T370346, T370347, T372594) and their custom references and utility Functions (T374533). We also added these new Types to the prohibited local content list; users should always load them from Wikidata, not try to store them on Wikifunctions (T373371).

In terms of user-facing bug fixes, we fixed editing of Objects to not stop regular users making an edit if it was not fully initialised, e.g. if you were trying to add or adjust a label to a Type that doesn't have an Equality Function set (T374931). We think this may have been the issue underlying being unable to edit some pre-defined Objects, which I know has been irritating to a few of you (T362011).

We adjusted the behaviour of the general Object (and the more specific language selector) to work with how Codex now expects us to use it, following-up on our immediate bug-fix two weeks ago (T374248). We improved the restrictions in the object selector for situations like in Types or Implementations where you're selecting function calls (T372995).

We landed a coding tweak that made our front-end JS import format consistent with our new standard, already implemented in our Vue code (T334939).

We added support to the Wikifunctions stack for the new languages Haryanvi in Arabic script, Z1938/bgc-arab (T373561) and Negeri Sembilan Malay, Z1939/zmi (T373931), which have been added to MediaWiki for translations.

We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.13.0, as of this week. The colours used in Codex have slightly changed to be more accessible and work better with dark mode; otherwise, we believe that there should be no further user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue.

Last week, Yuntian Deng, a professor at the University of Waterloo, was discussing the accuracy of large language models when multiplying large integers, and it’s a really interesting discussion: it shows how much better the new GPT-o1 model is compared to the previous GPT-4o model on this particular task. Lastly, he points out that a “small” model with more than 100 million parameters can solve this task with over 99% accuracy for twenty-digit numbers.

In case you want 100% accuracy even with larger numbers and using far less energy, you are invited to use Wikifunctions: we have a function for multiplying two natural numbers that does the job very well!

The function offers five implementations:

• One in Python using Python’s * operator
• One in JavaScript using JavaScript’s * operator for BigInt
• One composition implements a recursive function, which first checks whether any of the two arguments is zero (and returns zero if so), and if not, it adds the greater number to the result of multiplying the greater number times the lesser number minus one. Or, put differently, it turns a×b into a + a×(b-1)
• One composition using the hyperoperation of rank 2
• And one more composition that turns the natural numbers into integers, uses integer multiplication, and then back again to a natural number

And five tests confirm that these implementations all work with 100% accuracy:

• 1×1 is 1 (testing the unit)
• 2×3 is 6
• 0×10 is 0 (testing the zero)
• 10×0 is 0 too (and commutativity for the last one)
• 2⁴²×2²⁴=2⁶⁶, or 4398046511104×16777216=73786976294838206464 (not 20 digits each, but pretty large numbers)

So, next time you need two large integers multiplied, we recommend Wikifunctions instead of ChatGPT.