The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-04-30
----
Abstract Wikipedia is a MacArthur 100&Change finalist
<https://www.wikifunctions.org/wiki/File:Flachgruende-SH-2024-msu-7624-.jpg>
Wikimedia’s vision is a world in which everyone can share in the sum of all
knowledge. And yet, some of the biggest challenges towards realizing this
goal are the barriers that exist between our 300 language editions of
Wikipedia. Finding a way to bring the different languages closer together
was central to the idea behind my 2013 post exploring a multilingual
encyclopedia
<https://meta.wikimedia.org/wiki/A%20proposal%20towards%20a%20multilingual%2…>.
I imagined Wikipedia written in a language-independent way that could be
used to fill the knowledge gaps that exist in many of its language editions.
In the following years, I explored this concept with linguists and other
scientists around the world, developed prototypes, and kept refining the
idea, presenting to scientific communities and publishing the progress in
leading journals
<https://cacm.acm.org/opinion/building-a-multilingual-wikipedia/>. This
work received extensive feedback over time and received encouraging
recognition in the form of two Computing Research Association Blue Sky
Awards
<https://cccblog.org/2019/02/27/great-innovative-idea-capturing-meaning-towa…>.
While all of these steps have been essential to our progress, no
stakeholder has been more important to the success of this project than
Wikimedia’s global volunteer communities.
Abstract Wikipedia was first proposed on Meta
<https://meta.wikimedia.org/wiki/Abstract%20Wikipedia/Historic%20proposal> in
May 2020, and the Wikimedia community discussed
<https://en.wikipedia.org/wiki/Wikipedia:Wikipedia%20Signpost/2020-04-26/In%…>
, improved, and expressed support
<https://meta.wikimedia.org/wiki/Talk:Abstract%20Wikipedia/Archive%201> for
the project proposal. The Wikimedia Foundation Board of Trustees passed a
resolution of approval
<https://foundation.wikimedia.org/wiki/Resolution:Abstract_Wikipedia>, and
in July 2020, Abstract Wikipedia was announced
<https://meta.wikimedia.org/wiki/Abstract%20Wikipedia/July%202020%20announce…>.
Since that time, it has been collaboratively developed with Wikimedia
communities, who named
<https://meta.wikimedia.org/wiki/Abstract%20Wikipedia/Wiki%20of%20functions%…>
it, gave it a logo
<https://meta.wikimedia.org/wiki/Abstract%20Wikipedia/Updates/2021-10-27>,
and helped with numerous technical decisions
<https://meta.wikimedia.org/wiki/Abstract%20Wikipedia/Updates/2022-07-29> along
the way.
Today, I am proud to share that this decade-plus of work and collaboration
has been recognized by the John D. and Catherine T. MacArthur Foundation
<https://en.wikipedia.org/wiki/MacArthur%20Foundation>, which has selected
Abstract Wikipedia as one of five finalists
<https://www.macfound.org/press/press-releases/five-finalists-announced-in-1…>
for
their 100&Change competition <https://www.100andchange.org/about>. This
competition provides a single $100 million, 5-year grant to fund an idea
that makes measurable progress toward solving a critical problem of our
time. Selected from 869 submissions, each of the five finalists will
receive a $1 million grant. The winner of the competition will be announced
in late 2025.
*What is the critical problem we want to solve?* For many people speaking
underrepresented languages, knowledge is not readily available, nor can
they contribute effectively to the world’s knowledge on Wikipedia.
The amount of knowledge that different language editions of Wikipedia offer
varies dramatically: English Wikipedia is about to reach 7 million
articles, German Wikipedia just reached 3 million, but more than a hundred
Wikipedia language editions have fewer than 10,000 articles. Perhaps even
more important than the number of articles though, is the size of a
language community to help write, curate, and fact-check articles. More
than a hundred thousand volunteers contribute to English Wikipedia every
month, but most other language editions have only a dozen or so
contributors. It is simply not possible to create and maintain a
comprehensive and up-to-date encyclopedia with only a dozen people.
*How do we aim to address this problem at scale?* At a time when more
trusted sources of information are badly needed, Abstract Wikipedia can be
a vital communication tool with the power to quickly and extensively expand
access to reliable knowledge on Wikipedia to billions globally.
A shared fact base is essential for well-functioning societies and for the
world to tackle big, global challenges. This is even more urgent as we see
growing challenges to the integrity of the internet’s knowledge base
including mis- and disinformation.
With information in 300+ languages, Wikipedia is the most multilingual
platform on the internet. To fully achieve its place as the world’s shared
fact base, it needs more tools that volunteers can use to make knowledge
available across more languages.
That is where Abstract Wikipedia comes in. Tackling this more
systematically, at scale, can help grow the quantity—and quality—of
human-created and checked content and translations online. A global
community creating human edited and maintained language-independent
knowledge can provide millions of articles in hundreds of languages where
they are currently missing, benefitting all Wikipedias, and aligning with
our principle of supporting human knowledge contributors.
*What has been achieved so far?* We have made significant progress to date,
starting with the launch of Wikifunctions in 2023—the first new Wikimedia
project since 2012 (when Wikidata was launched). Designed as a repository
of functions that can be accessed from any Wikimedia project, Wikifunctions
contributors from over 50 countries have already created more than 2400
functions with names and descriptions for those functions in more than a
hundred languages. 2024 saw us enable access to Wikidata data from
Wikifunctions.
And just a few weeks ago, we celebrated the first roll-out of Wikifunctions
in a Wikipedia project. We share our collective progress through weekly
updates <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates>—this
being its 200th edition!
Winning the 100&Change prize would help us build on this communal momentum
to accelerate implementation and meet the urgency of the moment: funding
things like more strategic and sustainable expertise, infrastructure, and
outreach. We are honoured to be a 100&Change finalist, and are deeply
grateful to the many people who have helped us achieve all that we have so
far.
Abstract Wikipedia has been fortunate to receive ongoing support by the
Wikimedia communities and funding from the Wikimedia Endowment, The
Rockefeller Foundation, and Google.org. We look forward to this support and
partnership with the MacArthur Foundation to create a future in which every
human can share in the sum of all knowledge.
Wikidata Lexeme Forms now has support for Quechua
As Lucas Werkmeister
<https://www.wikifunctions.org/wiki/User:Lucas_Werkmeister> announced on
Mastodon <https://wikis.world/@LucasWerkmeister/114384150073717636>,
the Wikidata
Lexeme Forms
<https://www.wikidata.org/wiki/Wikidata:Wikidata%20Lexeme%20Forms> tool now
has support for creating and editing Quechua
<https://en.wikipedia.org/wiki/Quechuan%20languages> verbs, including
Wikifunctions to automatically generate forms based on the infinitive,
thanks to Elwin Huaman <https://www.wikifunctions.org/wiki/User:Elwinlhq>!
🎉
Links:
- live template
<https://lexeme-forms.toolforge.org/template/quechua-verb/>
- wiki page
<https://www.wikidata.org/wiki/Wikidata:Wikidata%20Lexeme%20Forms/Quechua>
- Quechua function catalogue
<https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue/Natural_language…>
Team members at Wikimedia Hackathon in Istanbul
This weekend, 2–4 May, is the Wikimedia Hackathon 2025
<https://www.mediawiki.org/wiki/Wikimedia%20Hackathon%202025> in Istanbul,
Türkiye. A number of Abstract Wikipedia team members will be at the
Hackathon: James <https://www.wikifunctions.org/wiki/User:Jdforrester_(WMF)>
, Geno <https://www.wikifunctions.org/wiki/User:Geno_(WMF)>, Cory
<https://www.wikifunctions.org/wiki/User:CMassaro_(WMF)>, Elena
<https://www.wikifunctions.org/wiki/User:Etonkovidova_(WMF)>, and David S.
<https://www.wikifunctions.org/wiki/User:DSantamaria-WMF>. Stop by and say
hello! If you have a project related to Wikifunctions and Abstract
Wikipedia, let us know – we would love to showcase it here next time!
Where will Abstract Wikipedia be located?
In the next few weeks we will start the conversation about where the
content of Abstract Wikipedia will be located. Stay tuned here, but we will
also reach out to other channels.
Recent Changes in the software
Over the past two weeks, a lot of our focus has been on fixes for issues
that came to light once the cross-wiki embedded Function calling went live.
We landed two tweaks to the Function-call editing experience when adding or
inserting Function calls into articles. We fixed a validation issue in the
editor when it has multiple enum inputs which are loading. We also fixed a
bug in displaying the 'read more' content with a paragraph in the wrong
position, due to a conflict from MobileFrontend's styles.
In terms of bugs, there were a few! We found a situation where bad user
input would trigger a server-side error, rather than respond appropriately (
T389702 <https://phabricator.wikimedia.org/T389702>). We fixed a similar
issue for MonolingualStringSets (as used in aliases) where the claimed
language wasn't valid (T391528 <https://phabricator.wikimedia.org/T391528>).
A third issue uncovered via malformed contents around strings was also
fixed (T392370 <https://phabricator.wikimedia.org/T392370>). We fixed the
REST API and Action API code to be disabled on client wikis, and not try
(and then fail) to read from the repo-only DB tables in such circumstances (
T392014 <https://phabricator.wikimedia.org/T392014>). We down-graded a
warning from the update code that we believe is triggered when deploying
the code to production (and so things are in an inconsistent state between
servers), and fixed the structured data it passes along when editing a Test
case or Implementation related to a Function. Finally, we fixed our
error-calling code to use consistent keys, so errors actually return
correctly rather than trigger server-side errors (T392026
<https://phabricator.wikimedia.org/T392026>).
We also made some progress on the other Quarterly work. We added a caching
step to the post-publishing code for edits to Objects, which will in future
allow client wikis' code to quickly check Objects' Types without expensive
network fetches, to allow for "blank value" support. We similarly added
support for additional caching in the back-end service, which (once the new
infrastructure is built for us by SRE) we hope will allow much faster
Function calling (T390743 <https://phabricator.wikimedia.org/T390743>).
We made one general UX tweak, changing the selector component to remove the
chevron icon in favour of a search icon, based on user testing where the
old icon was confusing (T350683 <https://phabricator.wikimedia.org/T350683>
).
We tweaked the browser tests to account for a design change when we moved
to re-use Codex's table component (T387464
<https://phabricator.wikimedia.org/T387464>). We then tweaked the last two
failures to wait for the element to be clicked correctly, which allowed us
to run all the browser tests (T391733
<https://phabricator.wikimedia.org/T391733>), a key milestone towards our
complete use of the new Catalyst testing platform for our integration and
end-to-end system testing (T368002
<https://phabricator.wikimedia.org/T368002>).
We finally landed a series of unit test coverage improvements written for
us two years ago (!) by User:William Avery
<https://www.wikifunctions.org/wiki/User:William_Avery> (T294826
<https://phabricator.wikimedia.org/T294826>); they had been blocked by some
inconsistencies between different parts of our system, which we have now
resolved. Thank you again, and sorry for the long delay.
We refactored some of our API error code to be shared and so more
consistent. We switched our Pinia router to use mw.util.getUrl rather than
$.param directly, which seems to be incompatible with newer versions of
jest testing. This allowed us to upgrade our jest testing to 29.7.0, which
had long been awaited, and then the test version of Codex to match
MediaWiki's. All these manual upgrades meant our other test tooling could
be automatically upgraded, including phan for PHP static analysis, and
mediawiki-wdio and related tool for browser testing.
Finally, we've added support for the Z1969/hoc-latn language (T391731
<https://phabricator.wikimedia.org/T391731>), as part of MediaWiki adding
support for it.
Volunteers’ Corner on Monday
On Monday, 5 May 2025, at 17:30 UTC
<https://zonestamp.toolforge.org/1746466200>, we will have our monthly
Volunteers’ Corner. Unless you have many questions, we will follow our
usual agenda, of giving updates on the upcoming plans and recent
activities, having plenty of time and space for your questions, and
building a Function together. Looking forward to seeing you online
<https://meet.google.com/xuy-njxh-rkw> on Monday!
Function of the Week: first plural Lexeme form for a Wikidata Item
Given a Wikidata item, give me a word in a language that refers to it – and
give me the plural form of that word.
That is what the function does that we are looking at this week. So for
example, we look at Q146 <https://www.wikidata.org/wiki/Q146> —the Wikidata
item for house cat-– and ask for the plural form in Dagbani, and it returns
*Jɛnkunti*. If we ask for the respective plural form in English, we get
*cats*.
The Function has two arguments,
- the Wikidata item <https://www.wikifunctions.org/wiki/Z6091> and
- the language <https://www.wikifunctions.org/wiki/Z60> in which we want
the Lexeme form in,
and the Function returns a Lexeme form
<https://www.wikifunctions.org/wiki/Z6004>.
This is a nice example of a function that moves from the abstract,
ontological space —represented by Wikidata QIDs— to actual words. It is not
entirely functional, since it picks the “first” plural form, without regard
to what other grammatical features that form might have (e.g. the case or
definiteness, depending on the language). But as a function it is a good
demonstration, and the tests and implementations also offer a good
opportunity to learn about the relevant functions in that area.
There are seven tests for this function:
- A Breton plural <https://www.wikifunctions.org/wiki/Z23086> for dog is
*chas*
- An English plural <https://www.wikifunctions.org/wiki/Z23083> for dog
is *dogs*
- An English plural <https://www.wikifunctions.org/wiki/Z23084> for fox
is *foxes*
- An French plural <https://www.wikifunctions.org/wiki/Z23085> for hat
is *chapeaux*
- An English plural <https://www.wikifunctions.org/wiki/Z23088> for
sheep is *sheep*
- An English plural <https://www.wikifunctions.org/wiki/Z23089> for
people is *peoples*
- A German plural <https://www.wikifunctions.org/wiki/Z23781> for wolf
is *Wölfe*
The last of these tests didn’t work at time of writing, and was thus not
connected. The reason it didn’t work is due to Wikidata having two items
for wolf, one for the species *canis lupus
<https://www.wikidata.org/wiki/Q18498>* and one for the vernacular name *wolf
<https://www.wikidata.org/wiki/Q3711329>*, which according to Wikidata may
also encompass a few other species, such as the African golden wolf
<https://www.wikidata.org/wiki/Q20744349> or the Ethiopian wolf
<https://www.wikidata.org/wiki/Q188957>. The German Lexeme *Wolf* was only
connected to the species, but not to the vernacular name – but the test was
asking for the vernacular name. I connected it now to the vernacular name
as well, and once the caches are refreshed, the last test should work too.
It would be interesting to see tests covering non-European languages a bit
more regularly in such functions.
The Function has two implementations, both connected and both compositions
(which is not a surprise, since only compositions can access Wikidata data
currently):
- The first composition <https://www.wikifunctions.org/wiki/Z23087> works
as follows:
- We ask for the first Lexeme from an item reference based on a given
language <https://www.wikifunctions.org/wiki/Z22696>. For this, we
use the two arguments given to this function.
- Then we filter for only the lexeme forms with a specific
grammatical feature, plural <https://www.wikidata.org/wiki/Q146786>,
using the select lexeme forms from lexeme
<https://www.wikifunctions.org/wiki/Z19243> function.
- Since that returns a list, we ask for the first element
<https://www.wikifunctions.org/wiki/Z811> of that list.
- The second composition is a bit simpler, as it uses a function which
does most of the work already:
- It returns the first element
<https://www.wikifunctions.org/wiki/Z811> of the plural Lexeme forms
for a Wikidata item <https://www.wikifunctions.org/wiki/Z23604>
function.
You may now think that the plural Lexeme forms for a Wikidata item
<https://www.wikifunctions.org/wiki/Z23604> function is just the same as
the first two steps used in the first composition, but it is not: the
composition
for that function <https://www.wikifunctions.org/wiki/Z23605> works
with a filter
function <https://www.wikifunctions.org/wiki/Z872> instead.
All in all, an interesting function with surprisingly diverse
implementations, showcasing the step from an abstract representation to
actual words.
Fresh Functions weekly: 34 new Functions
This week we had 34 new functions. Here is a list of functions with
implementations and passing tests to get a taste of what functions have
been created. This week, there are a lot of Functions about linear algebra.
Thanks everybody for contributing!
- fallback languages (Z24144) <https://www.wikifunctions.org/wiki/Z24144>
- append element to Typed list conditionally (Z24150)
<https://www.wikifunctions.org/wiki/Z24150>
- String of monolingual text list (Z24159)
<https://www.wikifunctions.org/wiki/Z24159>
- sum rational matrices (Z24162)
<https://www.wikifunctions.org/wiki/Z24162>
- same list of rationals (Z24166)
<https://www.wikifunctions.org/wiki/Z24166>
- same rational matrix (Z24171)
<https://www.wikifunctions.org/wiki/Z24171>
- transpose rational matrix (Z24176)
<https://www.wikifunctions.org/wiki/Z24176>
- dot product (rational vectors) (Z24185)
<https://www.wikifunctions.org/wiki/Z24185>
- right product of matrix with vector (Z24191)
<https://www.wikifunctions.org/wiki/Z24191>
- discard tail of Typed list after first match (Z24203)
<https://www.wikifunctions.org/wiki/Z24203>
- Cartesian product as two lists (Z24207)
<https://www.wikifunctions.org/wiki/Z24207>
- list of language codes to languages (Z24219)
<https://www.wikifunctions.org/wiki/Z24219>
- Year to century in English (Z24222)
<https://www.wikifunctions.org/wiki/Z24222>
- Year to century in Spanish (Z24229)
<https://www.wikifunctions.org/wiki/Z24229>
- left multiplication between vector and matrix (Z24236)
<https://www.wikifunctions.org/wiki/Z24236>
- matrix multiplication (Z24239)
<https://www.wikifunctions.org/wiki/Z24239>
- select representations from forms by language (Z24240)
<https://www.wikifunctions.org/wiki/Z24240>
- Year to millennium in English (Z24244)
<https://www.wikifunctions.org/wiki/Z24244>
- create 2x2 matrix (Z24251) <https://www.wikifunctions.org/wiki/Z24251>
- representations from lexeme form by language (Z24255)
<https://www.wikifunctions.org/wiki/Z24255>
- Newton's method next estimate (rational) (Z24262)
<https://www.wikifunctions.org/wiki/Z24262>
- x^2−2 (rational) (Z24263) <https://www.wikifunctions.org/wiki/Z24263>
- double (rational) (Z24266) <https://www.wikifunctions.org/wiki/Z24266>
- Newton's method, n iterations (rational) (Z24271)
<https://www.wikifunctions.org/wiki/Z24271>
- select lexeme forms from lexeme by language (Z24280)
<https://www.wikifunctions.org/wiki/Z24280>
- prepend 0 to vector (Z24285)
<https://www.wikifunctions.org/wiki/Z24285>
- identity matrix (Z24290) <https://www.wikifunctions.org/wiki/Z24290>
- list of list of single object (Z24291)
<https://www.wikifunctions.org/wiki/Z24291>
- prepend column to matrix (Z24299)
<https://www.wikifunctions.org/wiki/Z24299>
- fallback language codes (strings) (Z24307)
<https://www.wikifunctions.org/wiki/Z24307>
A complete list of all functions sorted by when they were created
<https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderb…>
is
available.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-04-16
--
Wikifunctions integration live on Dagbani Wikipedia (and Test Wikipedia
and, oh my, Wikifunctions)!
We are happy to announce that this week we switched on the ability to call
Wikifunctions functions from within a wiki for the first time: the pilot
project is Dagbani Wikipedia.
Dagbani <https://en.wikipedia.org/wiki/Dagbani_language> is one of our five
focus languages
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-04-15>. It
is a Niger-Congo language (belonging to the Gur branch) spoken in northern
Ghana. Dagbani has about 3 million native speakers. Dagbani Wikipedia has
more than 12,000 articles. It is written in a Latin-based alphabet.
We are thankful to the Dagbani community for their collaboration over the
last few years while we've been developing Wikifunctions!
We also have a request for contributors. If you do not know Dagbani and are
not a member of the Dagbani community, please refrain from editing on
Dagbani Wikipedia. Let’s respect the Dagbani Wikipedia and the Dagbani
community.
But we understand that people want to try out the new functionality. This
is why we planned to deploy Wikifunctions integration on test2.wikipedia.org
as well. Unfortunately, that didn’t work—it turned out that there was an
incompatibility with the extension for Flagged Revisions
<https://www.mediawiki.org/wiki/Extension:FlaggedRevs>. Fortunately,
Dagbani does not use Flagged Revisions, and so we were still able to deploy
to Dagbani.
Instead of test2.wikipedia.org, we went for test.wikipedia.org. Some of you
already found our test page on test.wikipedia.org
<https://test.wikipedia.org/wiki/Wikifunctions#Tests?useparsoid=1>. There
is a caveat, though: our integration depends on Parsoid
<https://www.mediawiki.org/wiki/Parsoid>, but test.wikipedia does not yet
use Parsoid by default. There are two ways around this:
1. Add the query parameter ?useparsoid=1 to each URL (as in
https://test.wikipedia.org/wiki/Wikifunctions?useparsoid=1). But note
that this query parameter is not “sticky”: when you click to the next page,
you will loose the parameter.
2. If you are logged in, opt-in on test.wikipedia.org to always use
Parsoid in your User Preferences > Editing
<https://test.wikipedia.org/wiki/Special:Preferences#mw-prefsection-editing>
>
Developer tools.
This way you can try it out on test.wikipedia.org.
Finally, we also decided to integrate Wikifunctions on Wikifunctions. So,
yes, you can just try it out here as well! {{#function:Z22725|What can go
wrong?}} I'm sure the Wikifunctions community will swiftly decide on how
and on what page to test this feature. Note that you also need to enable
parsoid here in order to see the results — or click here
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-04-16?…>
.
A tutorial on how to integrate functions will be made available in the next
few days.
If you find a bug, a malfunction or a problem, please let us know.
Have fun!
Function(s) of the Week: date of Gregorian Easter and date of Julian Easter
*The Function of the Week is a column written by the community. Planning
the column and submissions can be made here
<https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Functio…>.
Thanks to User:99of9 <https://www.wikifunctions.org/wiki/User:99of9> for
writing this submission.*
This week we are discussing date of Gregorian Easter
<https://www.wikifunctions.org/view/en/Z23254> and date of Julian Easter
<https://www.wikifunctions.org/view/en/Z23269>. Both functions were written
by User:Dv103 <https://www.wikifunctions.org/wiki/User:Dv103>, a relatively
new contributor to Wikifunctions, who has also already contributed a
variety of Italian <https://www.wikifunctions.org/view/en/Z1787> language
functions and complex date functions. For Christians like me, Easter
<https://en.wikipedia.org/wiki/Easter> is the most important religious
weekend of the year, celebrating Jesus' death and resurrection. The date of
Easter Sunday <https://en.wikipedia.org/wiki/Date_of_Easter> is computed
based on a lunisolar calendar, but varies by tradition, with most Orthodox
churches using the Julian calendar and Catholic and Protestant churches
using the Gregorian calendar. The date also has secondary social and
economic consequences. For example, when writing software to forecast daily
operations activity for a company twenty-five years ago, I recall
hard-coding the dates of Easter up until 2030, as an important input. This
week's functions let us calculate these dates for any year.
These functions take one input, the Gregorian year
<https://www.wikifunctions.org/view/en/Z20159> in which we want to know the
date of Easter and return the day of the Roman year
<https://www.wikifunctions.org/view/en/Z20342> that Easter falls on in the
Gregorian calendar for that year.
A variety of tests are available:
- Gregorian: 2 April 1961 <https://www.wikifunctions.org/view/en/Z23256>
- Gregorian: 5 April 2026 <https://www.wikifunctions.org/view/en/Z23265>
- Gregorian: 18 April 2049 <https://www.wikifunctions.org/view/en/Z23263>
- Gregorian: 30 March 2070 <https://www.wikifunctions.org/view/en/Z23266>
- Gregorian: 19 April 2076 <https://www.wikifunctions.org/view/en/Z23262>
- Julian: 27 April 2008 <https://www.wikifunctions.org/view/en/Z23270>
- Julian: 19 April 2009 <https://www.wikifunctions.org/view/en/Z23271>
- Julian: 1 May 2016 <https://www.wikifunctions.org/view/en/Z23272>
It's nice to see a variety of past and future dates. No years from the BC
era are tested, because those would not make much sense since Easter was
not yet celebrated. It would be nice to verify some dates of some early
Easters to test if the implementations are accurate over a millenium-scale.
Beware, though: when adding tests, it's important not just to use the
output of a function, but instead to seek independent verification of the
actual values—otherwise, they are not truly tests!
One implementation is available for each function:
- Gregorian: Meeus/Jones/Butcher's algorithm in Python
<https://www.wikifunctions.org/view/en/Z23264> based on an algorithm
published anonymously in *Nature* in 1876, and frequently republished
under different names.
- Julian: Jean Meeus's algorithm
<https://www.wikifunctions.org/view/en/Z23273> in Python which calculates
<https://en.wikipedia.org/wiki/Date_of_Easter#Meeus's_Julian_algorithm> the
date in the Julian calendar first, then adds an offset (currently 13 days)
to convert it to a Gregorian date.
These functions extend our date functions into the cultural sphere, and are
a nice model and resource for other events with complex date methodologies.
A fabulous general example, also by User:Dv103, is their use of value of
Wikidata claim to day of the year
<https://www.wikifunctions.org/view/en/Z23474>, which draws on Wikidata and
can deal with a variety of different date methodologies. Perhaps when the
code I wrote for my former employer fails in 2030 (or sooner if they read
the documentation), they will switch to calling our functions in the
Wikifunctions
API <https://api.wikimedia.org/wiki/Wikifunctions_API>?
How about this year? Two final tests: Gregorian 2025 Easter
<https://www.wikifunctions.org/view/en/Z23255> and Julian 2025 Easter
<https://www.wikifunctions.org/view/en/Z23437> coincide this year on 20
April. The last such coincidence was in 2017. Happy Easter, once for all.
Recent Changes in the software
We landed a lot of work related to the Wikipedia integration. We re-wrote
our integration with MediaWiki to use the new "asynchronous fragments"
system from Parsoid (T388546 <https://phabricator.wikimedia.org/T388546>).
We finished up the cross-wiki update system, adding entries into Recent
Changes as needed, like how Wikidata does it (T386020
<https://phabricator.wikimedia.org/T386020>). We made the editing
experience more fluent, setting a nice 'loading' state when you have added
or editing a Function call in the visual editor (T391441
<https://phabricator.wikimedia.org/T391441>).
We added a bunch of logging and did some general debugging to find out
issues, of which there were a few. We fixed the URL used by the cross-wiki
front-end editor so that browsers did not think we were diluting security
measures, but instead let the editor work (T391534
<https://phabricator.wikimedia.org/T391534>). We fixed a bug in the
Function search tool in the editor where the "read more" link for
descriptions that are too long would show incorrectly (T387362
<https://phabricator.wikimedia.org/T387362>). We fixed a couple of errors
we noticed in edge cases around the editor when interacting with
partially-written Function calls. We simplified the way we create the job
to update cross-wiki usage of Functions to avoid a state error (T391533
<https://phabricator.wikimedia.org/T391533>). We fixed our code to block
users from the Wikifunctions-only special pages when on client wikis (
T391594 <https://phabricator.wikimedia.org/T391594>). We switched the
cross-wiki encoding mechanism to preserve all user inputs, not just most,
which we hadn't spotted in our testing (T391584
<https://phabricator.wikimedia.org/T391584>). Finally, we added a
feature-flag to let us disable Function calls if something goes wrong,
without breaking existing pages, so that we feel comfortable rolling it out
to the first wiki.
Alongside all the above, we also landed a few improvements in other areas,
partially hold-over items from FixIt Week two weeks ago. We tweaked the
layout of the "Cancel" and "Publish" buttons when editing the "About" box
so they don't overflow if they have been translated to be long (T377403
<https://phabricator.wikimedia.org/T377403>). For safety, we've added some
fallback rate limits for running Functions. This should not have any
effect, as we already have a different form of rate limiting running, but
we thought it worth using the normal system as well just in case. If you
notice any issues with this, please report them! We consolidated the code
that generates the "footer" in the publish dialog into a single component (
T372293 <https://phabricator.wikimedia.org/T372293>).
We dismantled the last remnants of our code pointing to the old Beta
Cluster version of Wikifunctions, which had stopped working a year ago (
T374242 <https://phabricator.wikimedia.org/T374242>). We then closed down
that service. We re-enabled one of our API integration tests that used to
break back when we were using the Beta Cluster for testing.
We also fixed the little-used public fetch handler to not error if users
don't specify the optional parameters (T391046
<https://phabricator.wikimedia.org/T391046>). We're now stashing a copy of
Objects into a cache as you edit them, which we hope will allow us to do
some cross-wiki and back-end operations more swiftly in future (T390745
<https://phabricator.wikimedia.org/T390745>). We switched out various old
PHP aliases to the current class names, to unblock wider MediaWiki renaming
work. We updated a couple of documentation references to old Codex systems
that have since been renamed, to allow them to release the new, breaking
change later this month (T390983 <https://phabricator.wikimedia.org/T390983>
).
We expanded the default browser tests that get run to cover all of them (
T391733 <https://phabricator.wikimedia.org/T391733>), in preparation for
using the new Catalyst system from our colleagues in the Testing Platform
team. We removed one old technology use from our browser tests (T331484
<https://phabricator.wikimedia.org/T331484>), which will in future allow
them to be upgraded to a newer framework, once everyone else has done such
things.
We have added support for one natural language, Z1968/hav (Kihavu), as part
of Wikimedia-wide support (T390871
<https://phabricator.wikimedia.org/T390871>).
As always, if you have any issues, please report them on the project chat,
or directly on Phabricator.
News in Types: Date type now with read and display functions
The Gregorian calendar date Type
<https://www.wikifunctions.org/view/en/Z20420> has had a display function
<https://www.wikifunctions.org/view/en/Z20780> for a while, and now we've
also connected the parse Gregorian date
<https://www.wikifunctions.org/view/en/Z20808> read function. This will
simplify the UX for using dates considerably, and also allow the usage of
functions with dates in the connected wikis. Thanks to Feeglgeef
<https://www.wikifunctions.org/wiki/User:Feeglgeef> and 99of9
<https://www.wikifunctions.org/wiki/User:99of9> for defining the Function
and for writing the implementations and the tests.
Next NLG SIG meeting on 20 May
This week’s NLG SIG meeting was cancelled, as no topics were suggested for
the agenda. The next meeting is planned for 20 May 2025, if someone suggests
a topic on the NLG SIG page
<https://www.wikifunctions.org/wiki/Wikifunctions:NLG_SIG>.
Fresh Functions weekly: 44 new Functions
This week we had 44 new functions. Here is a list of functions, usually
with implementations and passing tests to get a taste of what functions
have been created. A great number of Quechua linguistic functions this
time! Thanks everybody for contributing!
- Classifying sentence in English (Z23726)
<https://www.wikifunctions.org/view/en/Z23726>
- Object as Wikidata item reference (Z23742)
<https://www.wikifunctions.org/view/en/Z23742>
- label of item reference in language (Z23753)
<https://www.wikifunctions.org/view/en/Z23753>
- Wikidata item reference from Wikidata item (Z23756)
<https://www.wikifunctions.org/view/en/Z23756>
- Integer list from Natural number list (Z23772)
<https://www.wikifunctions.org/view/en/Z23772>
- Quechua verb, 1PS present conjugation (Z23782)
<https://www.wikifunctions.org/view/en/Z23782>
- Neralie timestamp (Z23783)
<https://www.wikifunctions.org/view/en/Z23783>
- Quechua verb, 2PS present conjugation (Z23788)
<https://www.wikifunctions.org/view/en/Z23788>
- Quechua verb, 3PS present conjugation (Z23790)
<https://www.wikifunctions.org/view/en/Z23790>
- Quechua verb, 1PP inclusive present conjugation (Z23792)
<https://www.wikifunctions.org/view/en/Z23792>
- Quechua verb, 1PP exclusive present conjugation (Z23795)
<https://www.wikifunctions.org/view/en/Z23795>
- Quechua verb, 2PP present conjugation (Z23798)
<https://www.wikifunctions.org/view/en/Z23798>
- Quechua verb, 3PP present conjugation (Z23800)
<https://www.wikifunctions.org/view/en/Z23800>
- Unix timestamp from Gregorian calendar date (Z23801)
<https://www.wikifunctions.org/view/en/Z23801>
- Gregorian calendar date from Unix timestamp (Z23808)
<https://www.wikifunctions.org/view/en/Z23808>
- English to Pig Latin (Z23827)
<https://www.wikifunctions.org/view/en/Z23827>
- Natural numbers in Telugu script (Z23843)
<https://www.wikifunctions.org/view/en/Z23843>
- Vigenère cipher (Z23848) <https://www.wikifunctions.org/view/en/Z23848>
- decrypt Vigenère (Z23851)
<https://www.wikifunctions.org/view/en/Z23851>
- format Unix timestamp (Z23865)
<https://www.wikifunctions.org/view/en/Z23865>
- encrypt Caesar (custom alphabet) (Z23869)
<https://www.wikifunctions.org/view/en/Z23869>
A complete list of all functions sorted by when they were created
<https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderb…>
is
available.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-04-11
--
Quarter in review
It’s a new Quarter! Last week, we published the plan for the next three
months, and today we will review how we did on last Quarter’s plan
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-01-15>
.
- *Provide Wikifunctions integration in articles on Dagbani Wikipedia:* We
made significant progress, but it has not been fully deployed yet. We
informed the Dagbani community on Wednesday that we are hoping to deploy
this feature next week. It will then also be available on test2wiki – we
reiterate our request to be respectful of the Dagbani community and not use
their wiki as a sandbox, unless you are part of their community.
- *Provide updates to editors when Wikifunctions calls are changed:* This
work was tied up in the above, and is also very close to slightly-delayed
completion. We hope that next week's deployment for Dagbani Wikipedia will
also include this working fully.
- *Expand Wikidata access on Wikifunctions to support multi-lingual
functions:* Functions are now available that allow to get Lexemes based
on Wikidata items, and these are being used in Functions in Wikifunctions.
- *Improve performance and drive down tech debt & developer
inhibitors:* There
has been significant improvement in performance on the back-end, and
Functions that previously timed out are now possible.
- *Plan for wider adoption and rollout of Wikifunctions to more
Wikipedias:* Two plans have been written, though both needed re-writes.
We need to follow after the Parsoid-roll out, and we plan to roll out to
Wikipedias in the focus language and Wiktionaries early.
- *Fix high-priority papercuts:* We identified a series of "papercut"
tasks, and though we planned to address at least two, we ended up fixing
six of them, including collapsed views of argument references, using the
display functions for inner values, and adding guidance pointing to
Wikifunctions.Debug when tests aren't working.
- *Create testing strategy via participation in the test engagement
pilot:* This was internal work to engage with our colleagues focussed on
code quality so we can try out their new model of supporting teams. We've
documented our systems and how we're currently testing them, identifying
where the gaps are, how we'd like things to work, what we need and the
tradeoffs of different approaches, and the role of Pixel, Catalyst, and
other testing tools. We're going to continue this work as background
"essential work" this Quarter, prioritising what we're going to focus on
next.
- *Prepare for a future Rust implementation:* This work was also mostly
internal, working with our colleagues in Security and Site Reliability
Engineering to plan out how this would work. We hope to give a further
update about this soon.
Thank you for following along!
Last week's service outages
We had two connected outages last week, due to some networking changes.
The changes are part of a work to simplify the networking for MediaWiki (
T384944 <https://phabricator.wikimedia.org/T384944>), as part of the
Wikimedia Foundation's Annual Plan work on making development and
deployment faster and simpler (WE6.2
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>
).
The first outage on Wednesday last week had parts of the Wikifunctions.org
wiki being broken (both full pages and static assets, but inconsistently).
This was because the new networking layer was sometimes pointing requests
to a server that had none of the code, and so would return a 404 page. Once
this happened and was noticed, the experiment was unwound and service was
restored after an hour or so.
The second outage occurred the next day, when with the previous issue fixed
it was deployed again. This time the issue was a subtle bug in the HTTPS
networking layer, that was dropping the site headers for requests (T391022
<https://phabricator.wikimedia.org/T391022>). Because the back-end
"orchestrator" service has to talk to both Wikifunctions.org and
Wikidata.org to fetch the data for function calls, we use multiple site
headers rather than just one, so this affected us but not other services or
testing. In practice, this broke all function calls that weren't built-in
Functions; an emergency hot-patch was written on Thursday night, fixing the
issue for main production, and then rolled out properly on Friday, which
fixed the consequent breakage of the hot-spare service cluster (T391047
<https://phabricator.wikimedia.org/T391047>).
There are various follow-up pieces of work we're considering based on this
outage, so that hopefully neither it nor similar issues will ever recur.
Again, we're very sorry for the disruption, and thank community members who
helped us diagnose and fix the issues.
Recent Changes in the software
Last week was Fix It Week, our regular session every two months where we as
a team focus on fixing technical debt, little bugs, and other gremlins, to
ensure that we are able to extend the systems we develop as smoothly and
swiftly as possible.
We've provided a new built-in Function to fetch multiple Wikidata entities
at once, Z6820 (T386598 <https://phabricator.wikimedia.org/T386598>). We're
adding a Type hint to what map function (Z873)
<https://www.wikifunctions.org/view/en/Z873> returns to be a list of Z1s (
T367005 <https://phabricator.wikimedia.org/T367005>); thanks to Feeglgeef
<https://www.wikifunctions.org/wiki/User:Feeglgeef>. We updated the "Ace"
code editor used in the Code component from 1.37.1 to 1.39.1, to mirror the
same change in the CodeEditor extension for MediaWiki code pages, which
also landed this week.
In the mode selector, we now prohibit the selection of "Literal" for some
Types, such as Z46s <https://www.wikifunctions.org/view/en/Z46> and Z64s
<https://www.wikifunctions.org/view/en/Z64>; we were already excluding
enums and Wikidata items here, but now this should operate more fluently (
T387190 <https://phabricator.wikimedia.org/T387190>). We fixed a bug that
meant input validation errors would sometimes display in a very long
vertical form (T390879 <https://phabricator.wikimedia.org/T390879>). We
adjusted the flow of the "About", "Cancel", and "Publish" buttons in edit
mode, so if they have long labels they should still display in a readable
way (T377403 <https://phabricator.wikimedia.org/T377403>). We fixed a bug
when editing an Implementation that meant switching the target Function did
not update the Code block (T337750
<https://phabricator.wikimedia.org/T337750>), and another to update the
Function explorer when you change the target Function (T337753
<https://phabricator.wikimedia.org/T337753>).
We created the three outstanding Help: documentation pages: about the main
view page for Objects
<https://www.mediawiki.org/wiki/Help:Wikifunctions/Viewing_Objects>, the
page for [[:mw:Help:Wikifunctions/Missing labels|finding Objects without
labels, and the page for finding Functions with Tests in various states
<https://www.mediawiki.org/wiki/Help:Wikifunctions/Functions_by_Test_status>.
We also categorised and slightly cleaned up the other Help: pages (T362241
<https://phabricator.wikimedia.org/T362241>).
We've fixed the rendering of formulæ from the "Math" extension by disabling
the legacy SVG option, which is being removed from all wikis and was never
available on Wikifunctions.org. We now don't show the 'details' dialog
button on Test case or Implementations when they've not yet finished
running.
In the Wikipedia integration work, we landed a re-write of the error
messages and flow shown to users in each of the edge cases, such as when
trying to use a Function that doesn't exist or not giving enough inputs (
T387359 <https://phabricator.wikimedia.org/T387359>). We also expanded our
test suite for this code (T387560
<https://phabricator.wikimedia.org/T387560>). We added a fix to the part of
the integration that adds entries in Recent Changes to not break if a used
Function was deleted (T391033 <https://phabricator.wikimedia.org/T391033>).
We switched around some more of our front-end code to stop our code
documentation system thinking those bits are injecting global functions (
T362925 <https://phabricator.wikimedia.org/T362925>). We fixed a code field
focus bug, where it would try to call a non-existent method from the store
instead of the correct one. We moved our custom front-end field validation
code in the Publish dialog to use Codex's system now that it exists,
simplifying code and making things more consistent (T388565
<https://phabricator.wikimedia.org/T388565>). We refactored our front-end
constants file to make it easier to work with (T357681
<https://phabricator.wikimedia.org/T357681>). We've adjusted our code to
consolidate creation of view URLs into a single helper (T342570
<https://phabricator.wikimedia.org/T342570>).
We improved the front-end API fetching code to handle the error state of an
Object not existing, rather than caching a bad state (T383671
<https://phabricator.wikimedia.org/T383671>). We added a fix to the
middleware API for running Functions to return an appropriate error on
malformed user input, rather than logging a server error (T389702
<https://phabricator.wikimedia.org/T389702>).
We've replaced our disabled end-to-end API tests with integration tests
that use a mock (T360373 <https://phabricator.wikimedia.org/T360373>)
rather than the broken Beta Cluster service, which we're planning to shut (
T374242 <https://phabricator.wikimedia.org/T374242>).
Plenty of material about Abstract Wikipedia and Wikifunctions!
<https://www.wikifunctions.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…>
- Jens Ohlig <https://www.wikifunctions.org/wiki/User:Jens_Ohlig> wrote
a lovely short story about Abstract Wikipedia: The Glass of Milk and the
Monsters’ Feast
<https://johl.io/blog/the-glass-of-milk-and-the-monsters-feast/>.
- The Recording of this week’s Volunteers’ Corner is available on Commons
<https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…>
.
- Denny gave a talk on the topic of Knowledge in the Age of AI
<https://www.youtube.com/watch?v=2oFrs86xtco> at King’s College, London.
A recording of the talk can now be watched on the King’s College's YouTube
channel.
- Also available is an interview by King’s College Student Union
president Baiyu Liu with Denny
<https://www.kcl.ac.uk/meet-dr-denny-vrandecic>.
- The podcast Between the Brackets had three episodes recently which
touched on Wikifunctions and Abstract Wikipedia, with Selena Deckelman
<https://betweenthebrackets.libsyn.com/episode-176-selena-deckelmann>, Ward
Cunningham
<https://betweenthebrackets.libsyn.com/episode-179-ward-cunningham> (where
Ward talks about Federated Wiki, which seems to have similarities with
Wikifunctions), and most recently Denny Vrandečić
<https://betweenthebrackets.libsyn.com/episode-180-denny-vrandei>. One
note: even though Yaron refers to Abstract Wikipedia as the “dystopia of
replacing Wikipedia with function calls” in his talk with Selena and Denny,
that isn’t on our road map: Abstract Wikipedia aims to fill in gaps, not to
replace existing articles.
NLG SIG Meeting planned for 15 April
On 15 April 2025 at 16:00 UTC <https://zonestamp.toolforge.org/1744732800> we
are planning the next NLG SIG meeting. We currently have no topic planned
for that day. If there is no topic suggested at the NLG SIG page
<https://www.wikifunctions.org/wiki/Wikifunctions:NLG_SIG> 24 hours before
the meeting, we will cancel the meeting. Topics for this and future
meetings can be proposed at the NLG SIG page.
Fresh Functions weekly: 33 new Functions
This week we had 33 new Functions. Here is a list of Functions with
implementations and passing tests to get a taste of what Functions have
been created. Thanks everybody for contributing!
- is Integer (type)? (Z23645)
<https://www.wikifunctions.org/view/en/Z23645>
- is float64 an integer? (Z23656)
<https://www.wikifunctions.org/view/en/Z23656>
- Rational number as simplest type (Z23660)
<https://www.wikifunctions.org/view/en/Z23660>
- number as Rational number (Z23668)
<https://www.wikifunctions.org/view/en/Z23668>
- is float64? (Z23672) <https://www.wikifunctions.org/view/en/Z23672>
- is Wikidata statement rank preferred? (Z23683)
<https://www.wikifunctions.org/view/en/Z23683>
- is Wikidata statement preferred? (Z23688)
<https://www.wikifunctions.org/view/en/Z23688>
- prototype Wikidata entity reference picker (Z23694)
<https://www.wikifunctions.org/view/en/Z23694>
- constrained Wikidata statement value (Z23716)
<https://www.wikifunctions.org/view/en/Z23716>
This week many of the new Functions are still in an experimental
state. A complete
list of all Functions sorted by when they were created
<https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderb…>
is
available.
The on-wiki version of this newsletter edition can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-04-05
--
Quarterly Planning for April–June 2025
As with the previous Quarters, we are publishing our plan for the upcoming
Quarter to make our work more transparent.
- (T390543 <https://phabricator.wikimedia.org/T390543>) If we establish
and meet performance standards, we can have confidence that rolling out
Wikifunctions access to more wikis will not disrupt those wikis'
experiences or colleagues' work
- (T390548 <https://phabricator.wikimedia.org/T390548>) Establish an
SLO for the Wikifunctions integration into Wikimedia projects' wikitext
pages, to assure reader experience quality is maintained during roll-out
- (T390549 <https://phabricator.wikimedia.org/T390549>) Implement
Object and Wikidata entity caching mechanisms in the
function-orchestrator
to drive up user experienced performance when making function calls
- (T390550 <https://phabricator.wikimedia.org/T390550>) Implement
Object and Wikidata entity batching mechanisms in the
function-orchestrator
to drive up user experienced performance when making function calls and
reduce load on production wikis
- (T390544 <https://phabricator.wikimedia.org/T390544>) If we roll out
Wikifunctions access to more Wikimedia wikis, we will see wider use to
deliver content and learn how well it works with different languages and
communities to address content gaps
- (T390551 <https://phabricator.wikimedia.org/T390551>) Make embedded
Wikifunctions available in at least five more Wikimedia
projects, to learn
from other languages and communities
- (T390552 <https://phabricator.wikimedia.org/T390552>) Listen to
feedback from the pilot Dagbani Wikipedia community and adapt
features, so
that we can identify blockers to further rollout, and increase value to
editors and readers, and so help the community
- (T390545 <https://phabricator.wikimedia.org/T390545>) Improve features
related to the Wikifunctions integration, so that wiki editors can use
Wikifunctions in articles with more confidence.
- (T390553 <https://phabricator.wikimedia.org/T390553>) Support
default values when fields are left blank for date inputs in the
Wikifunctions integration so that editors can use it more simply
- (T390554 <https://phabricator.wikimedia.org/T390554>) Show
read-mode errors from the Wikifunctions integration inline
rather than in a
box, so that editors can be less disrupted when something is wrong
- (T390555 <https://phabricator.wikimedia.org/T390555>) Show a
preview of the function call result in the Wikifunctions integration
dialog, so that editors can adjust their uses more swiftly
- (T390557 <https://phabricator.wikimedia.org/T390557>) Display the
local and cross-wiki pages on which a Function is used, so that
Wikifunctions users can see the impact of their changes
- (T390546 <https://phabricator.wikimedia.org/T390546>) Extend features
to use Wikidata items more fluently, so that Wikifunctions editors can do
more things and so address content gaps more readily.
- (T390558 <https://phabricator.wikimedia.org/T390558>) Support a
light-weight enum Type alternative in the Wikifunctions front-end and in
the Wikifunctions integration so that editors can use them more easily
- (T390559 <https://phabricator.wikimedia.org/T390559>) Extend
support for Wikidata items to cover unitful values and other
types, so that
function creators can take advantage of more of the content features of
Wikidata
- (T390560 <https://phabricator.wikimedia.org/T390560>) Improve the
performance in the Wikifunctions front-end, so that function creators and
users can use complex and large Objects such as those from
Wikidata without
difficulty
- (T390547 <https://phabricator.wikimedia.org/T390547>) Build plans in
the Abstract Wikipedia team on how to address common concerns and proposed
feature expansions, so that we can be prepared for taking this on in future.
- (T390561 <https://phabricator.wikimedia.org/T390561>) Experiment
with how we might support rich content as output, including in the
Wikifunctions integration, so that we can see how to support future use
cases. Develop a plan based on this.
- (T390563 <https://phabricator.wikimedia.org/T390563>) Develop a
plan for how we might support macro-languages like Chinese, so
that we can
see how to support them as groups in future
- (T390564 <https://phabricator.wikimedia.org/T390564>) Discuss with
the Wikifunctions community and others where we might host
Abstract Content
in the future, so that we can prepare for that work
On top of the above planned work, we'll also have some "essential work",
where we respond to bug fixes and emergency situations following our
standard protocols, aimed at reducing disruption for the Wikifunctions
community and its users.
We previously set out our plan for the "Q3" Quarter
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-01-15>,
January–March 2025, at the start, and we'll report on how that went next
week.
We are looking for a Senior Product Manager
The Abstract Wikipedia team is looking for a Senior Product Manager
<https://job-boards.greenhouse.io/wikimedia/jobs/6770261> to work with us.
The Senior Product Manager is accountable for turning the vision of
Abstract Wikipedia into a tangible impact. This is a one-of-a-kind
opportunity to build the future of the Internet and radically expand access
to free knowledge. You will be working on an international team. More
information, such as the countries we are hiring in and a list of
requirements, can be found on Greenhouse
<https://job-boards.greenhouse.io/wikimedia/jobs/6770261>.
Recent Changes in the software
As stated above, last week was our last of Q3. The biggest of those pieces
of work was the Wikipedia integration, to make it possible to embed
Wikifunctions calls in Wikipedia articles (and other Wikimedia wikis). (
T383106 <https://phabricator.wikimedia.org/T383106>).
We're getting close with our work on this, and have been making some
near-final changes whilst waiting for system support work to land upstream,
lots of which landed for release this week. We added not-yet-enabled
support for a new DOM syntax for how Wikifunctions calls will appear in the
page HTML (T373253 <https://phabricator.wikimedia.org/T373253>). In the
search system, we tweaked the display of results from Wikifunctions when
the descriptions are too long (T387362
<https://phabricator.wikimedia.org/T387362>). We've added support for Type
inputs that have read functions, like natural numbers (T387371
<https://phabricator.wikimedia.org/T387371>). We've provided a special icon
to represent Function calls for use in the editing tools (T388563
<https://phabricator.wikimedia.org/T388563>), and a colourful version of
the Wikifunctions logo for the editing dialog, as it's so more readable (
T387372 <https://phabricator.wikimedia.org/T387372>). We aligned the
display of labels, aliases, and short descriptions with the expectations
from, and the design shown to, various community members (T387361
<https://phabricator.wikimedia.org/T387361>). Finally, we added some unit
tests for all this new code (T387560
<https://phabricator.wikimedia.org/T387560>).
Outside of the Quarterly work, we fixed a bunch of bugs and minor
irritations. We switched our localisation code to use the translatable
message for ':' rather than hard-coding it, as it's over-ridden in some
languages (T385710 <https://phabricator.wikimedia.org/T385710>). We fixed a
bug that meant that sometimes we passed an incomplete value as an argument
into a Function call (T360580 <https://phabricator.wikimedia.org/T360580>).
We now remove the trailing ?success=true entry in the page URL when you
publish an edit (T389076 <https://phabricator.wikimedia.org/T389076>). We
adjusted the styling of labels in the list of Test cases associated with an
Implementation so they don't over-flow the box (T388794
<https://phabricator.wikimedia.org/T388794>). We fixed the styling for the
collapsible chevron which wrongly expanded size when you clicked into a
Type selector (T387204 <https://phabricator.wikimedia.org/T387204>). We
fixed a bug in the pre-publishing transformation code to avoid saving empty
booleans in Z3K4s, which we think might be causing wider issues (T390149
<https://phabricator.wikimedia.org/T390149>).
Volunteer’s Corner
Next week, on Monday, 7 April 2025, at 17:30 UTC
<https://zonestamp.toolforge.org/1744047000>, we will have our monthly
Volunteers’ Corner. Unless you have many questions, we will follow our
usual agenda, of giving updates on the upcoming plans and recent
activities, having plenty of time and space for your questions, and
building a Function together. Looking forward to seeing you online
<https://meet.google.com/xuy-njxh-rkw> on Monday!
Fresh Functions weekly: 33 new functions
This week we had 33 new functions. Here is a list of functions with
implementations and passing tests to get a taste of what functions have
been created. Thanks everybody for contributing!
- statement has value type string? (Z23513)
<https://www.wikifunctions.org/view/en/Z23513>
- value type of statement (Z23516)
<https://www.wikifunctions.org/view/en/Z23516>
- is undulating number (Z23523)
<https://www.wikifunctions.org/view/en/Z23523>
- statement has value type QID? (Z23528)
<https://www.wikifunctions.org/view/en/Z23528>
- statement has value type Lexeme ID? (Z23531)
<https://www.wikifunctions.org/view/en/Z23531>
- statement has value type LFID? (Z23534)
<https://www.wikifunctions.org/view/en/Z23534>
- statement has value type LSID? (Z23537)
<https://www.wikifunctions.org/view/en/Z23537>
- predicate is P31 (Z23540)
<https://www.wikifunctions.org/view/en/Z23540>
- item is instance of these items (Z23543)
<https://www.wikifunctions.org/view/en/Z23543>
- identity value of Kleenean object (Z23558)
<https://www.wikifunctions.org/view/en/Z23558>
- is ISBN-13 (Z23561) <https://www.wikifunctions.org/view/en/Z23561>
- not in (Z23568) <https://www.wikifunctions.org/view/en/Z23568>
- object inequality (Z23578)
<https://www.wikifunctions.org/view/en/Z23578>
- identity of Floating point special value (Z23588)
<https://www.wikifunctions.org/view/en/Z23588>
- is Wikidata reference to Roman day? (Z23592)
<https://www.wikifunctions.org/view/en/Z23592>
- is Wikidata day of the week within a given month (Z23596)
<https://www.wikifunctions.org/view/en/Z23596>
- is Wikidata reference of day relative to Easter (Z23600)
<https://www.wikifunctions.org/view/en/Z23600>
- plural Lexeme forms for a Wikidata Item (Z23604)
<https://www.wikifunctions.org/view/en/Z23604>
- flatten Typed list (Z23606)
<https://www.wikifunctions.org/view/en/Z23606>
- lexeme forms representing item (Z23610)
<https://www.wikifunctions.org/view/en/Z23610>
- Lexemes from Wikidata item reference (Z23616)
<https://www.wikifunctions.org/view/en/Z23616>
A complete list of all functions sorted by when they were created
<https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderb…>
is
available.
