Recording of Wikimania session: Wikifunctions is coming soon to a wiki near you!
At this year’s Wikimania in Nairobi, we presented on the current state of Wikifunctions, highlighting what the community has achieved so far. We discussed the results of our first live deployment to Wikimedia projects, what this means for editors and readers of those wikis, and our plans for further integration with other Wikimedia projects.
The presentation was followed by a tutorial that provided an introduction to Wikifunctions. We gave a high-level overview and then did a set of introductory activities, each of which can be done on our project. These activities included finding and calling existing functions; creating new and editing existing functions, tests, and implementations; and showing how community members are using these function calls on projects where Wikifunctions has been enabled. We focused on functions that generate sentences and fragments in several languages.
Thanks to James Forrester for presenting, and to everyone for joining the session, especially the volunteers helping during the tutorial! Thanks to everyone who joined the session either in person or online.
Recent Changes in the software
In the past three weeks, we spent most of our time on the bigger pieces of work planned for this Quarter, but we also fixed a number of bugs.
To unblock our Quarterly work to support Wikidata references in embedded Wikifunctions calls, we added a quick wrapper to make Wikibase's tracking nominally compatible with the modern parser (T398993). We plan to work with Wikimedia Deutschland to build the proper version of this in the future, to fully support all use cases and other tools than ours (T397353). We have added support for default values for Wikidata items when inputs are left blank (T398733). We also added some support for using Natural language (Z60) references as inputs, as they're often needed when calling Functions related to Wikidata items and particularly Lexemes (T400165), and allowed for default values for these being the page's display language (T400240). More generally, we extended our integration with the VisualEditor so that it recognises all of these new default values as valid (T402177).
As part of our work on Wikidata items support, we have added Z6007 and associated updates for representing claims on-wiki (T399423). The server-side code to fill these went live on Thursday, so the new, expanded content is made available (T399424). Also, we've landed a change on-wiki to tweak the calendar options for Z6063/Calendar model (T391208). Finally, we'll be adding Z861 as a helper Function to let you easily create Z11/Monolingual strings, mostly to support the Abstract Wikipedia prototyping work and similar efforts; this still needs the server-side code, which will come soon.
Our thanks to User:SomeRandomDeveloper, who found and provided a fix for a security issue that made it possible for any sysop on Wikifunctions.org (even if they didn't have edit-interface rights) to run bad code on editors' browsers (T400500). Though never abused, this kind of risk is not acceptable for us, so we immediately deployed this fix. Thank you again!
We have updated a few very rare Function-related rights, like changing how many values of true/false the system knew about, that were originally handed out to sysops; they're now more appropriately issued to Function maintainers.
We fixed an issue where malformed language values would try to add an unknown language to the page's HTML (T400521). We made a quick fix that might help PHP reason better about how to handle a null case when fetching Objects (T365728). We added logging around issues with cached results (T398410). Finally, we reduced the noise from logging around failed requests where it might be intended, such as a Test case checking that dividing by zero throws an error (T397996).
Our thanks to User:Zabe for their work helping all of Wikimedia code, including us, to upgrade to a new version of the database access layer, re-generating our SQL schema to match. We cleaned up some of our code around Objects' storage on, and loading from, the wikis to use dependency injection (T394839). We landed another patch from User:Zabe as part of Wikimedia-wide work to drop use of a deprecated database field (T36320), and another from User:SomeRandomDeveloper adjusting a reference we were making to a class that is being moved (T402038); thank you both!
We undertook a set of changes around how our code handles nested Functions, because they are error-prone due to confusion from our front-end (T398457). First, we changed our canonicalisation code to be consistent between the middleware and back-end rather than sometimes renaming keys, then changing the front-end code to recognise that references in calls are "terminal", and shouldn't expand further, making the UX flow more easily in this rare edge case. Next, we changed how we show this kind of Function call in collapsed mode: showing a blank state instead of "Select …" if something's not been selected yet, except in edit mode, and showing the full call, with a different display if the called Function is defined through argument references. Finally, we added to the editing interface an ability to specify local keys manually when a Function call is dynamic and so can't be automatically completed by the UX.
We fixed a UX bug in the Object selector to show the already-selected option, instead of "no results found" (T398453). We've also changed the mode selector for Wikidata entity to also allow adding a Function call and not just an argument reference, which is sometimes needed (T400990) e.g. when working with lexeme forms (T386553). We've corrected our embedded Wikifunctions calls code to lower the cache time when inserting the day's date as a default value for a time. Finally, we've further expanded our testing for the API that embedded Wikifunctions calls make when a used input Type does not have a reader Function, or the used output Type does not have a display Function.
News in Types: Wikidata geo-coordinate
Recently Wikifunctions started importing Wikidata statements containing values of the new Wikifunctions types Wikidata quantity, Wikidata geo-coordinate, and Wikidata time. In the last update we described Wikidata quantity; here we give an overview of Wikidata geo-coordinate.
Each instance of Wikidata geo-coordinate (which corresponds directly to the geo-coordinates datatype on Wikidata) contains 4 components: latitude, longitude, precision (all of type Rational number), and globe (of type Wikidata item reference). Latitude and longitude are required to be present; precision is optional and, when its value is missing from imported Wikidata content, is filled in with Z24/void. Globe usually refers to the Wikidata item for Earth (Q2), but can also refer to other astronomical bodies.
To support more natural implementations in JavaScript and Python of functions that take or return instances of Wikidata geo-coordinate, there are converter functions to and from each of those languages. Going from ZObject instance to JavaScript, Convert from Wikidata geo-coordinate, JavaScript converts each Rational number to a BigInt, extracts the Wikidata identifier of the globe from the Wikidata item reference, and collects these 4 elements into a single JavaScript Object. Convert from Wikidata geo-coordinate, Python provides similar conversions resulting in a Python dictionary. Going in the other direction, the converters from those two languages reverse the transformations.
We’d particularly like to highlight the versatile display and read functions, prepared primarily by community member 99of9. The display function builds on the existing Rational number display function to show the latitude and longitude in decimal form (preserving the number of decimal places that appears in Wikidata), and separated by commas. If the globe item is anything other than Earth, the display function also presents its label, retrieved from Wikidata. The read function, in addition to reading those two numbers (and accommodating a variety of language-specific number formats), employs a lookup table to recognize the names, in many different languages, of the bodies of our solar system, and map them to the identifier for the corresponding Wikidata item (from which it can reconstruct the original Wikidata item reference).
The screenshots show the statements containing the coordinate locations of Hickory, North Carolina (Wikidata item Q2028564) and the Tycho crater (Wikidata item Q631696) on the moon, including the output of the display function (under the word “value”). These statements show up in this way when the items are fetched using Fetch Wikidata item.