We now have the option to use natural languages as a default value in embedded function calls. If an argument of Type natural language is omitted, we automatically use the language of the page as the default value for that argument.
Together with Wikidata items and Gregorian calendar dates, this allows for quite powerful flexibility: for example, a function call can omit a date, a Wikidata item and a language, and automatically apply to the item of the page, return in the language of the given wiki, and use the current date for its calculation. Such a call can then be copied and pasted from one article to another — even across different language Wikipedias or Wiktionaries!
We don’t have a function yet that uses all three default values, but if you make one that is useful for Wikipedias, let us know! We would love to feature it here.
For example, one of the most frequently occurring sentences on English Wikipedia is “She is a vegetarian.” or “He is a vegetarian.”, respectively.
Now, one can have an embedded function call such as
{{#function:Z26039||Q18338317|}}If you copy that into the article of Brian May on English Wikipedia (once we deployed to English Wikipedia), it will show the following sentence:
You can copy and paste that exact same call to the article about Paul McCartney on English Wikipedia, and get the following sentence:
You can also copy it to the German Wikipedia article of Paul McCartney, and you will get the following sentence:
Or Swedish:
Or Arabic:
Or Esperanto:
And once that is done, you can go back to the article about Brian May in English, and change it to:
{{#function:Z26039||Q27522900|}}Which will result in the slightly more correct sentence:
Now, if we only had a way to update that in all languages at once… 😉[1]
Thanks to Visual Editor, you wouldn’t be editing the raw QIDs, but use a form-based editor to create and maintain the function call. Only when using the raw source editor, you would be confronted with ZIDs and QIDs directly.
As part of our work this Quarter to improve the usability of the experience when using Wikifunctions embedded in wiki articles (T397411), we have improved the experience to show custom, translatable errors in the interface (T402382). This allows the Wikifunctions community to get more value when they create clear, specific error types and throw them from their code, helping end-users understand what they might have done wrongly and how to fix it. We plan to write some guidance on how to use this feature, and encourage its use, in the near future.
Alongside this work, we've been spending a fair bit of time this Quarter re-writing the back-end function evaluator service to use Rust rather than Node, as it is better suited at juggling multiple WASM sub-processes (T343720). Last week we reached the milestone of the prototype Rust code running the lifecycle of routing an incoming call to the correct JavaScript or Python executor (T399321), and maintaining a ready pool of executors to which to route requests (T399322). We have also switched the base images over to use Node 22, up from Node 20, as part of wider Wikimedia service updates.
We unfortunately had a partial service outage on Wednesday afternoon/evening US time, caused by a corrupted cached Object (T403671). The caching layer we added last Quarter for Objects had a flaw that meant it would cache whatever the API gave it, including a corrupted/broken item, and would not re-try. In this case, the crucial Type Z13518/Natural number was mis-cached, and because it is used in many different other Types and Functions, it led to a widespread inability to use the system. We made some urgent fixes to discard error Objects from the cache, and not cache them in future, and emergency deployed the new version of the service that night, fixing new calls. Earlier attempted calls may be cached in a bad state, but these will expire and be replaced over time. Our apologies again for all affected, and our thanks to Wikifunctions community members who first spotted the issue and alerted us to it.
We implemented two new enumerations, Grammatical person (3) (Z27970) and Celtic mutation (Z27971).
Many languages have the notion of a grammatical person, and they often have three distinct grammatical persons: referring to the speaker, or to the listener, or to someone else. Based on the proposal by Dv103, we now have an enumeration for these three values.
Breton and other Celtic languages are characterised by consonant mutations at the beginning of certain words. In order to describe them easier, a proposal by Dv103 to identify the five different mutations has been made, agreed on, and implemented.
We also tried to create a Type for Chemical element, but due to the unprecedented size of the Type for us, it surfaces two issues so far, which we are currently working on. We hope to have these fixed soon.
There are further type proposals, and I will assess them regularly and keep implementing them – particularly those that have consensus, or wide support. So, keep making proposals, keep discussing and voting on the existing proposals, and we keep implementing them.
Fresh Functions weekly: 36 new Functions
Last week the community created 36 new functions. Here is an incomplete list of functions with implementations and passing tests to get a taste of what functions have been created. Thanks everybody for contributing!
A complete list of all functions sorted by when they were created is available.