Jump to content

Wikifunctions:Status updates/2025-06-21

From Wikifunctions
Translate this page
◀ Wikifunctions Status updates Translate ▶

Abstract Wikipedia via mailing list Volunteer Response Team Abstract Wikipedia on IRC Wikifunctions on Telegram Wikifunctions on Mastodon Wikifunctions on Twitter Wikifunctions on Facebook Wikifunctions on YouTube Wikifunctions website Translate

Quarterly Planning for July–September 2025

Each Quarter, we are publishing here our plan for the upcoming three months to make our work more transparent. We previously set out our plan for the "Q4" Quarter, April–June 2025, at the start, and we'll report on how that went soon.

The Foundation's annual cycle runs from July to June the next calendar year. This year's annual plan includes the central "Objective" around which our team's work is centred, Wiki Experiences (WE) 2, "Vital Knowledge":

Make more vital knowledge available and well illustrated across languages and topics.

In general, the Abstract Wikipedia team has three strategic goals for our roadmap — Technical Foundation, Build Community, and Prepare for Scale. Our focus this year is mainly on the Technical Foundation side, building out the features for Wikifunctions so that it can demonstrate the Abstract Wikipedia vision of generating language-independent articles in any language based on Wikidata content. We have expressed this in the annual plan as Key Result WE2.2, to "build the platform capabilities needed to validate that we can support the Abstract Wikipedia vision at scale".

We have several strands of work, which we're organising below under our three areas, set out below.

Technical Foundation

For the Abstract Wikipedia vision to be exciting, interesting, and meaningful, we need to demonstrate through real, working systems the abilities so that the on-wiki communities can make credible, high-value vital knowledge in multiple languages.

This Quarter, we have a number of pieces of feature and technical work that we think will help our on-wiki communities build credible Functions:

  • Rich text/HTML: If we enable Wikifunctions to output HTML tables, styling, and links, we will demonstrate through a Function that displays a conjugation table its capability for generating net new knowledge on Wiktionaries beyond simple conversions.
  • Usability fixes based on Dagbani community testing. If we address usability findings from the Dagbani community, editors will encounter fewer or zero critical usability issues during testing and we will see an increase in use of embedded Wikifunctions in wikis.
  • Provide a Wikidata lexeme sense component. If we provide a Wikidata lexeme sense component into the Wikifunctions UI, then contributors will be able to identify and select relevant lexemes without leaving the platform/Wikifunctions—reducing context switching and enabling faster and more successful creation of language-related Functions.
  • Wikidata in embedded Function calls: If we add support for Wikidata entities in embedded Function calls, we will enable over 200 new Functions that can generate comprehensive sentences using Wikidata entities, making Functions more easily used on Wikimedia projects.
  • More complete access to Wikidata content: If we provide import of Wikidata statements with qualifiers, it will be possible to generate multifaceted facts (facts requiring more than just subject/predicate/value to express), which includes an estimated 50% of encyclopedic content in Wikidata.
  • More performant access to Wikidata content: If we provide caching of retrieved Wikidata entities, we will reduce by at least 50% the average runtime of Wikidata content-based Functions, reducing timeouts and user frustration.
  • Increase stability when running Function calls: If we make our backend-internal request format more expressive and concise, we can increase the system's stability, thereby supporting a broader rollout.
  • [Product Spike] Explore citations support: If we define and socialize across Product & Technology teams on the product needs for citations that are required for Abstract Content, we will be able to drive cross-Wikimedia work to deliver provenance information attached to Abstract Content, which is crucial for successful take-up across wikis.

Build Community

For the Abstract Wikipedia vision to be a success, we need to plan for how communities will use, control, and collaborate around the Abstract Content, so that any vital knowledge it can create is actually meaningfully available in multiple languages.

This Quarter, we plan to continue the conversation around how Abstract Content will work, demonstrating content that shows how it works, so that we have answers for how on-wiki communities will use it:

  • [Product Spike] Scope of abstract location work: If we build out an architecture plan for where Abstract Content will reside and how it will interact with Wikipedia, we will be more ready to implement the Abstract Wikipedia platform to increase provision of high-quality encyclopedic content.
  • Demonstrated NLG Abstract Content: If we provide prototype fragments using Wikidata and Wikifunctions calls to generate natural language snippets, we will show readiness for the project, and will be ready for it to be used to train AI so humans don't have to think too much about functions.

Prepare for Scale

For the Abstract Wikipedia vision to be usable and scalable to serve many topics in many languages, we need to make sure that it is fast for users as they read and edit, rapid to update when underlying data sources change, and low-cost for the servers so that it is scalable.

This Quarter, we plan to continue the roll-out of the existing embedded feature to new on-wiki communities, so that we can learn from them how well the tools work, what new issues different languages and communities find, and where we can add or expand features to better suit different forms of knowledge and community:

  • Rollout: If we follow Parsoid’s rollout and integrate Wikifunctions on most Wiktionaries and some low-traffic Wikipedias, we will get the testing we need to confidently roll out to larger wikis.

Alongside the items above, we also plan some essential work, first to do better capacity planning for the back-end services, and second to continue our Rust re-platforming of the back-end security-sensitive code-running evaluator service.

Recent Changes in the software

This week is a quieter one, with us landing some clean-up of recent features and capabilities.

On top of the back-end service caching system that we introduced last week (T390549), this week we will be enabling a new batching algorithm that should cause us to make fewer, more consolidated requests for Objects when we need to fetch them from the wiki (T390550). We also extended one of our maintenance scripts to be able to submit all of a Type of Object to this cache, which should allow us to ensure high cache performance even if the cache has to be re-built.

We also made a fair amount of progress towards a proof-of-concept of letting embedded Wikifunctions calls return rich text rather than plain text, and landed the front-end component for viewing and editing these (T391985). More to come soon!

We replaced the custom 'chip' components we were using for aliases to instead use the now-available Codex official version (T392702). We simplified some of our code around how we communicate between the Wikifunctions.org wiki software and the back-end services. We modernised the format returned by the API calls our front-end Vue code is using to talk to the wiki, to ensure consistency and avoid developer confusion.

We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v2.1.0, as of this week. We believe that there should be no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue.

News in Types

A few new built-in Types

In order to support Wikidata data better, we have introduced a few built-in Types: Wikidata time, Wikidata quantity, and Wikidata geo-coordinates. This week we deployed code that instantiates these new Types. Values of these 3 Types appear in statements inside of larger ZObjects containing Wikidata content, such as Wikidata item and Wikidata lexeme. These values are instantiated when one of the Wikidata fetch Functions is called, such as Fetch Wikidata item and Fetch Wikidata lexeme.

However, there are still some loose ends to be tidied up with respect to these three new Types:

  • Each of them relies on existing Types such as Natural number, Rational number, and Day of Roman year. We are noticing that the UI intermittently shows error messages from the display Functions for these Types. We believe this may be related to the current slowness in displaying large Wikidata entities. There is work underway that will yield a major improvement in this area. Until that work gets deployed, it is possible to bypass an error message and see the values by clicking on the relevant chevron (>) to open up the detailed view.
  • As noted on the Project chat page, Functions related to Day of Roman year may still need to be updated to handle a couple new conventions that we’ve adopted for unknown month and unknown year.

Please be mindful of these loose ends when writing implementations for the new Types, but as you can see in the next section, a lot of Functions have already been written for them. A few discussions about converters have already started. Thanks everyone!

Lightweight enum Types

The new "lightweight enum Type" capability, previously mentioned in the Status page, is now available.

A lightweight enumeration Type is a collection of Wikidata entity references, which are the possible values of the Type. Each instance of the Type is a small wrapper around one of the possible values. There are currently 5 initial examples of lightweight enum Types:

The first 3 of these may be useful in generating content in languages that use those groupings of gender concepts, as categorized in this Wikipedia list article. The other 2 are used in connection with the Wikidata time Type mentioned above.

There is an equality Function that can be used with instances of any lightweight enum Type. At least two other built-in auxiliary Functions are planned to increase the utility of lightweight enum Types, and should be available in the next week or two:

  • a Function that extracts the Wikidata reference from an instance of a lightweight enum Type (T397490)
  • a Function that reports the possible values of a lightweight enum Type (T397494).

Note that lightweight enumeration Types are different from ordinary enumeration Types, which were introduced in the Status update 2024-05-10. With an ordinary enumeration Type, each possible value is a persisted ZObject with its own ZID, whereas the possible values of lightweight enumeration Types are references to Wikidata entities (which do not have a local instantiation in Wikifunctions).

Fresh Functions weekly: 72 new Functions

This week we had 72 new Functions. Wohoo! 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!

A complete list of all Functions sorted by when they were created is available.

Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Status_updates/2025-06-21&oldid=198627"