Wikifunctions:Status updates/2025-04-16 - Wikifunctions

Wikifunctions:Status updates/2025-04-16 - Wikifunctions
Jump to content
From Wikifunctions
Wikifunctions:Status updates
Translate this page
Other languages:
Wikifunctions Status updates
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
is one
of our five focus languages
. 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
. 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
. There is a caveat, though: our integration depends on
Parsoid
, but test.wikipedia does not yet use Parsoid by default. There are two ways around this:
Add the query parameter
?useparsoid=1
to each URL (as in
). But note that this query parameter is not “sticky”: when you click to the next page, you will lose the parameter.
If you are logged in, opt-in on test.wikipedia.org to always use Parsoid in
your User Preferences > 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!
ȀA̰AĀ A̧AÂ A̋Å ȀȂÅÂA̋?
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
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
. Thanks to
User:99of9
for writing this submission.
This week we are discussing
date of Gregorian Easter
and
date of Julian Easter
. Both functions were written by
User:Dv103
, a relatively new contributor to Wikifunctions, who has also already contributed a variety of
Italian
language functions and complex date functions. For Christians like me,
Easter
is the most important religious weekend of the year, celebrating Jesus' death and resurrection. The
date of Easter Sunday
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
in which we want to know the date of Easter and return the
day of the Roman year
that Easter falls on in the Gregorian calendar for that year.
A variety of tests are available:
Gregorian: 2 April 1961
Gregorian: 5 April 2026
Gregorian: 18 April 2049
Gregorian: 30 March 2070
Gregorian: 19 April 2076
Julian: 27 April 2008
Julian: 19 April 2009
Julian: 1 May 2016
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
based on an algorithm published anonymously in
Nature
in 1876, and frequently republished under different names.
Julian:
Jean Meeus's algorithm
in Python which
calculates
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
, 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
How about this year? Two final tests:
Gregorian 2025 Easter
and
Julian 2025 Easter
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
). We finished up the cross-wiki update system, adding entries into Recent Changes as needed, like how Wikidata does it (
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
).
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
). 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
). 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
). We fixed our code to block users from the Wikifunctions-only special pages when on client wikis (
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
). 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
). 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
).
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
). 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
). 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
). 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
).
We expanded the default browser tests that get run to cover all of them (
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
), 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
).
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
has had a
display function
for a while, and now we've also connected the
parse Gregorian date
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
and
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
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
Object as Wikidata item reference (
Z23742
label of item reference in language (
Z23753
Wikidata item reference from Wikidata item (
Z23756
Integer list from Natural number list (
Z23772
Quechua verb, 1PS present conjugation (
Z23782
Neralie timestamp (
Z23783
Quechua verb, 2PS present conjugation (
Z23788
Quechua verb, 3PS present conjugation (
Z23790
Quechua verb, 1PP inclusive present conjugation (
Z23792
Quechua verb, 1PP exclusive present conjugation (
Z23795
Quechua verb, 2PP present conjugation (
Z23798
Quechua verb, 3PP present conjugation (
Z23800
Unix timestamp from Gregorian calendar date (
Z23801
Gregorian calendar date from Unix timestamp (
Z23808
English to Pig Latin (
Z23827
Natural numbers in Telugu script (
Z23843
Vigenère cipher (
Z23848
decrypt Vigenère (
Z23851
format Unix timestamp (
Z23865
encrypt Caesar (custom alphabet) (
Z23869
complete list of all functions sorted by when they were created
is available.
Retrieved from "
Categories
Status updates
Pages with Wikifunctions calls
Wikifunctions
Status updates/2025-04-16
Add topic