Wikifunctions:Status updates/2025-07-10
| ◀ | ▶ |
Length limits on labels and descriptions
Labels of functions are and will be used in many places: in compositions and for contributors, when a function call is embedded in Wikipedia, when searching for a function, and others. This is why it is necessary to limit the length of those labels: function names which are hundreds of characters long will be hard to use.
The front-end already limits the length of labels to 50 characters, and descriptions to 200 characters. This has been there for about a year, but the back-end hasn’t enforced these limits yet, as this might have led to data loss or to the inability to do certain contributions.
We have made a static list of all objects that have labels and descriptions that are too long, and we ask you for your help in fixing them. We currently have 1620 labels and descriptions which are too long, let’s try to push this number down!
Improvements to the front-end performance
We completed a large re-write of how the front-end components are created and tracked in the front-end store, switching from a flat table to nested objects (T396360). To make the impact of this work easier to understand, we made a video:
We originally switched from nested objects to a flat table in 2022, as we were concerned about the speed of tree-walking operations when making edits. However, three years later, we decided that the extra costs of this conversion back-and-forth now significantly out-weighs the advantages of simpler edit operations, as seen when viewing any large Object (especially, those fetched from Wikidata, whose use is already frequent, and increasing as the Wikifunction community builds more complex Functions).
Consequently, we migrated the entire storage system over to a new model, which is vastly faster (especially for more complex Objects). This also includes namespacing the store tables, reducing complexity when deleting detached Objects (T391136). We also found a few edge case bugs whilst re-writing the majority of the front-end test code, and expanding test coverage for this critical area of the front-end, and dropping now-unused code and constants. This work completes our front-end performance work for the last Quarter (T390560).
News in Types: Types for Wikidata datatypes
Recently we deployed types and import code for three important datatypes that are widely used on Wikidata. The three new Wikifunctions types are Wikidata quantity, Wikidata geo-coordinate, and Wikidata time. These types allow Wikifunctions to import Wikidata statements whose values have one of the datatypes quantity, geocoords, and time. Such statements are now showing up inside Wikidata entities (items, properties, lexemes, lexemes forms, and lexemes senses), whenever they are fetched using one of the Wikidata fetch functions.
Some keys of these types employ other types previously created by community effort, including Rational number, Gregorian calendar date, and Day of Roman Year.
The import of Wikidata quantity and Wikidata time must allow for missing values in some properties which are optional, by design, in Wikidata content. In Wikidata quantity, these include the lower bound and upper bound properties (keys). In Wikidata time, month and day, which are imported into instances of Day of Roman Year are often missing.
After some discussion, we've adopted the convention of inserting the special value Z24/void when there are missing values for lower bound, upper bound, and month. In the case of day, a missing value is indicated using 0 (zero), as it is in Wikidata.
New functions having inputs of type Wikidata quantity or Day of Roman Year should be written to allow for this new convention (unless they will never be used with content imported from Wikidata). Also, some of the existing Day of Roman Year functions, including converter, display, and read functions, will need to be updated to allow for the new convention.
Recent Changes in the software
As well as the major performance change listed above this week, we landed a number of smaller fixes.
We deployed a fix to the site "favicon" (used in browsers to identify the site e.g. in tabs' labels) so that it appears better in dark-themed browsers; our huge thanks to Jon Harald Søby for his work on this (T326094).
We fixed the keys for two of the new Types used for Wikidata Point-in-time, which meant using them could break the interface (T391208). We will deploy this manually ahead of the train this week, to remedy the breakage.
We changed the database code and the searchZObjectLabels API to fix searches for compound return Types, which meant that some uses of Typed lists would break (T396433). Thank you to 99of9 for the report so that we could fix it swiftly!
We landed a couple of follow-up fixes for our uses of Codex's Dialog and Message components now that we're all using Codex 2.0+, and switched our jest front-end unit testing to use the more modern event triggering system (T370511). We also fixed an error in our production monitoring that would in some cases fail to log the properties correctly, hampering debugging.
Upcoming NLG SIG meeting
The next meeting of the NLG SIG (Natural Language Generation Special Interest Group) will be on this upcoming Tuesday, July 15, 2025, at 16:00-17:00 UTC on Google Meet. Cory Massaro will lead a session on our upcoming work to demonstrate NLG content and create sentences in many languages. Everyone is invited to join!
Z-Template is broken
We are aware that the Z and Z+ templates are currently not working. Using the page tools, you can switch to the legacy parser in order to make them work again. We are investigating (T399081).
This week’s Volunteers’ Corner
We intentionally did not record this week’s Volunteers’ Corner, as we decided together with the present community members to use it for an informal chat and question and answer session. Also, we will skip the Volunteers’ Corner for August, as it overlaps with Wikimania. The next Volunteers’ Corner is planned for September 8.
Fresh Functions weekly: 42 new Functions
This week we had 42 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!
- n weeks earlier (Z25912)
- Serbian Latin to Serbian Cyrillic (Z25924)
- same Wikidata geo-coordinate (Z25932)
- rational from sign degrees minutes and seconds (Z25950)
- βγ from speed (Z25959)
- Plus Code from co-ordinates (Z25963)
- US CPI for year (Z25966)
- USD inflation calculator (Z25970)
- dir attribute (Z25974)
- is year in a standard format? (Z25982)
- multiply Wikidata quantity by rational number (Z25985)
- read year in a standard format (Z25991)
- read year, mul (Z26011)
- read year, Italian (Z26017)
- read Gregorian year, en (dmy) (Z26029)
- read Gregorian year, dag, en (mdy) (Z26033)
- read Gregorian Date in Chinese (Z26046)
- Week Number (ISO) (Z26059)
A complete list of all functions sorted by when they were created is available.