The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-06-27
--
How many people are needed to write an encyclopedia?
Well, if you’re Pliny <https://en.wikipedia.org/wiki/Pliny%20the%20Elder>,
you can do it alone.
<https://www.wikifunctions.org/wiki/File:Pliny_the_Elder,_Loggia_del_Consigl…>
But since then, encyclopedias have been written by teams. And our favorite
encyclopedia, Wikipedia, has been written by hundreds of thousands of
volunteer contributors.
It is amazing to have hundreds of thousands of volunteer contributors
working on an encyclopedia! We know that a diversity of contributors leads
to a more robust quality of the encyclopedia. We know that enough
contributors lead to more comprehensive coverage and to more current
updates in Wikipedia. But we also know that most Wikipedia language
editions have fewer than a dozen contributors. And that it is challenging
to write a comprehensive and up-to-date encyclopedia with so few volunteer
contributors.
Abstract Wikipedia aims to help with that issue by splitting up the *task
of writing an encyclopedia* into two tasks:
1. The abstract encyclopedists, who are creating and maintaining the
articles of the encyclopedia as Abstract Content
2. The language specialists, who are creating functions that take that
Abstract Content and turn it into concrete articles for the readers, in
their language
The abstract encyclopedists are expected to have a similar amount of work
as the current Wikipedia communities have. Maybe a constant factor more,
because it could be that doing their work using Abstract Content could be
more difficult – writing Abstract Content instead of text. So we can safely
expect that we will need many volunteer contributors to do so. This is also
continuous work, as the content of Wikipedia needs to be updated. We may
talk about the feasibility of this part some other day.
Today we want to focus on the team of language specialists. How large a
team do they need to be? How much work do they have? What does their effort
look like? They need to create and maintain the functions in Wikifunctions
and the lexicographic data in Wikidata to turn Abstract Content into
Wikipedia articles in a given language.
This is where the idea of Abstract Wikipedia shines: do we need thousands
and tens of thousands of language specialists for each language? No! They
can achieve their task with a team that is orders of magnitudes smaller.
And yet they will make a comprehensive and up-to-date encyclopedia
available in their language! Because they do not need to worry about the
content of the encyclopedia, or about keeping it up-to-date: they only need
to worry about the language generation functions and the lexicographic data.
The two main variables that determine the effort of the language
specialists are the number of natural language generation functions that
need to be implemented in that language, and the number of lexemes that are
needed. Both numbers are difficult to estimate at the current time: the
functions needed to achieve some reasonable coverage could range from 20 to
2000, the lexemes from a few hundreds to a few thousands.
If we estimate the effort to write a function to be about an hour, and to
create a lexeme to be ten minutes, this results in (20 to 2000)x60 + (100
to 10,000)x10 = 2,200 to 220,000 minutes, or roughly 40 to 4,000 hours. Or,
anywhere between a person week to a two person years. If we take the
average order of magnitude for the estimates, we end up with 400 hours. So,
with a group of five to ten people it would be one or two weeks of work.
But even a single dedicated person could get quite a bit of work done, and
they would see steady progress, unlocking more and more generated sentences
in their language edition of Wikipedia as they add functions and lexemes.
And the best part? Unlike the task of the abstract encyclopedists, who need
to keep the encyclopedia up to date, the task of the language specialist is
much more of a one-off: sure, there might be new words from time to time,
there might be new functions needed, but that effort can likely be
accomplished by a single volunteer contributor maintaining a whole language
encyclopedia. Language doesn’t change as quickly as knowledge.
Now, is this Fermi estimate reasonable? Do we have a set of comparable
experiences we can check this against? Yes! Grammatical Framework is a
system that allows for natural language generation. Their community runs
annual two-week summer schools, and one of the tasks they do is to add new
languages to Grammatical Framework. And within these two weeks, a student
or two can get quite far with realizing a language. This shows us that our
estimate is more or less reasonable, within an order of magnitude one way
or the other.
Whether it will really work out like this? I am excited to empirically
learn the answer. And I hope you are excited too!
Recent Changes in the software
This week we landed several smaller fixes and tweaks that get us closer to
completing our planned work for the Quarter that ends next week.
On Wikidata support, we've tweaked the Type definition for point-in-time (
T391208 <https://phabricator.wikimedia.org/T391208>). On the lightweight
enums side, we added a pre-defined Function, Z6895, to more easily get the
referenced Wikidata entity from the use, and its built-in Implementation (
T397490 <https://phabricator.wikimedia.org/T397490>). We've added
JavaScript converter functions and proposed Python converter functions for
the new Wikidata quantity type, and converter functions are nearly done for
Wikidata geo-coordinates. We thank the community for quickly contributing
display and read functions for Wikidata quantity; a display function for
Wikidata datetime; converter, equality, display, and read functions for
Time of day; and several more auxiliary functions for other related types.
As part of our work to build a prototype of using HTML in Function outputs (
T396606 <https://phabricator.wikimedia.org/T396606>), we're introducing a
pre-defined Equality function for instances of Z89/HTML fragment, Z877, and
its built-in Implementation, Z977.
We landed some more measurement instrumentation around the API used to make
Function calls and the code rendering embedded Function calls in pages,
which we expect to let us track several proposed SLIs (T394320
<https://phabricator.wikimedia.org/T394320>, T394322
<https://phabricator.wikimedia.org/T394322>, T394323
<https://phabricator.wikimedia.org/T394323>, T394324
<https://phabricator.wikimedia.org/T394324>, T394325
<https://phabricator.wikimedia.org/T394325>, and T394326
<https://phabricator.wikimedia.org/T394326>) feeding into our draft SLO (
T390548 <https://phabricator.wikimedia.org/T390548>).
We fixed and released early a bug that meant empty lists of Implementations
or Test cases would show with an "undefined" entry (T396978
<https://phabricator.wikimedia.org/T396978>).
We landed some fixes to the back-end services to better validate outputs of
user-written code, which should avoid some odd bugs and make issues more
immediately obvious and easier to understand (T395527
<https://phabricator.wikimedia.org/T395527>).
As part of wider work to use a newer logging library across MediaWiki
code, User:Fomafix tweaked our code type hints to allow this upgrade (
T356451 <https://phabricator.wikimedia.org/T356451>) — thank you!
We're adjusting the language code for Z1124 to adopt a new primary code,
'en-simple' (T394401 <https://phabricator.wikimedia.org/T394401>).
Fresh Functions weekly: 77 new Functions
This week we had 77 new functions. Quite a bit in cryptography, in music,
and for the new Wikidata data. Thanks everybody for contributing. Check out
the complete list of all functions sorted by when they were created
<https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderb…>
.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-06-21
--
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
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-04-05>,
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
<https://meta.wikimedia.org/wiki/Wikimedia%20Foundation%20Annual%20Plan/2025…>
includes
the central "Objective" around which our team's work is centred, Wiki
Experiences (WE) 2
<https://meta.wikimedia.org/wiki/Wikimedia%20Foundation%20Annual%20Plan/2025…>,
"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 <https://www.mediawiki.org/wiki/Abstract%20Wikipedia%20team#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 <https://phabricator.wikimedia.org/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 <https://phabricator.wikimedia.org/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 <https://phabricator.wikimedia.org/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
<https://phabricator.wikimedia.org/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 <https://www.wikifunctions.org/wiki/Z6064>, Wikidata
quantity <https://www.wikifunctions.org/wiki/Z6010>, and Wikidata
geo-coordinates <https://www.wikifunctions.org/wiki/Z6011>. 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 <https://www.wikifunctions.org/wiki/Z6001> and Wikidata
lexeme <https://www.wikifunctions.org/wiki/Z6005>. These values are
instantiated when one of the Wikidata fetch Functions is called, such as Fetch
Wikidata item <https://www.wikifunctions.org/wiki/Z6821> and Fetch Wikidata
lexeme <https://www.wikifunctions.org/wiki/Z6825>.
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
<https://www.wikifunctions.org/wiki/Z13518>, Rational number
<https://www.wikifunctions.org/wiki/Z19677>, and Day of Roman year
<https://www.wikifunctions.org/wiki/Z20342>. 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
<https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat#Indicating_un…>,
Functions related to Day of Roman year
<https://www.wikifunctions.org/wiki/Z20342> 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
<https://www.wikifunctions.org/wiki/Wikifunctions:Status#What_are_we_working…>,
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:
- Grammatical gender (m/f) <https://www.wikifunctions.org/wiki/Z25340>,
for masculine and feminine genders
- Grammatical gender (m/f/n) <https://www.wikifunctions.org/wiki/Z25501>,
for masculine / feminine / neuter genders
- Grammatical gender (c/n) <https://www.wikifunctions.org/wiki/Z25502>,
for common and neuter genders
- Wikidata calendar model <https://www.wikifunctions.org/wiki/Z6063>,
currently referencing Gregorian and Julian calendars
- Wikidata time precision <https://www.wikifunctions.org/wiki/Z6062>,
listing 15 levels of temporal precision used in Wikidata
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
<https://en.wikipedia.org/wiki/List%20of%20languages%20by%20type%20of%20gram…>.
The
other 2 are used in connection with the Wikidata time
<https://www.wikifunctions.org/wiki/Z6064> Type mentioned above.
There is an equality Function <https://www.wikifunctions.org/wiki/Z6894> 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
<https://phabricator.wikimedia.org/T397490>)
- a Function that reports the possible values of a lightweight enum Type
(T397494 <https://phabricator.wikimedia.org/T397494>).
Note that lightweight enumeration Types are different from ordinary
enumeration Types, which were introduced in the Status update 2024-05-10
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/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!
- Gregorian era is BC (Z25060)
<https://www.wikifunctions.org/wiki/Z25060>
- integer to digit string (hyphen negative) (Z25073)
<https://www.wikifunctions.org/wiki/Z25073>
- hour of day (Z25082) <https://www.wikifunctions.org/wiki/Z25082>
- minute from time of day (Z25085)
<https://www.wikifunctions.org/wiki/Z25085>
- second from time of day (Z25088)
<https://www.wikifunctions.org/wiki/Z25088>
- display Time of day (Z25091)
<https://www.wikifunctions.org/wiki/Z25091>
- time of day as hH:MM:SS string (Z25094)
<https://www.wikifunctions.org/wiki/Z25094>
- same times (Z25098) <https://www.wikifunctions.org/wiki/Z25098>
- time as 12-hour clock with AM/PM (Z25102)
<https://www.wikifunctions.org/wiki/Z25102>
- time of day as seconds past midnight (Z25108)
<https://www.wikifunctions.org/wiki/Z25108>
- less than or equal (Time of day) (Z25113)
<https://www.wikifunctions.org/wiki/Z25113>
- has leap second? (Z25152) <https://www.wikifunctions.org/wiki/Z25152>
- add to time of day (Z25167) <https://www.wikifunctions.org/wiki/Z25167>
- number of seconds from midnight to time of day (Z25179)
<https://www.wikifunctions.org/wiki/Z25179>
- fraction of regular day to time of day (Z25187)
<https://www.wikifunctions.org/wiki/Z25187>
- number of seconds in day (Z25191)
<https://www.wikifunctions.org/wiki/Z25191>
- integer modulo natural number (Z25196)
<https://www.wikifunctions.org/wiki/Z25196>
- is rational number 1? (Z25200)
<https://www.wikifunctions.org/wiki/Z25200>
- time as fraction of day (Z25207)
<https://www.wikifunctions.org/wiki/Z25207>
- frequency of pitch in A440 equal temperament (Z25217)
<https://www.wikifunctions.org/wiki/Z25217>
- difference between pitches in semitones (Z25219)
<https://www.wikifunctions.org/wiki/Z25219>
- distance from C in semitones (Z25220)
<https://www.wikifunctions.org/wiki/Z25220>
- semitones between pitches within an octave (Z25224)
<https://www.wikifunctions.org/wiki/Z25224>
- semitones between octaves (Z25227)
<https://www.wikifunctions.org/wiki/Z25227>
- semitone distance from A4 (Z25230)
<https://www.wikifunctions.org/wiki/Z25230>
- frequency ratio of semitone distance in 12TET (Z25232)
<https://www.wikifunctions.org/wiki/Z25232>
- era from calendar date (Z25248)
<https://www.wikifunctions.org/wiki/Z25248>
- Catholic Easter day (Z25262)
<https://www.wikifunctions.org/wiki/Z25262>
- is it Catholic Easter? (Z25266)
<https://www.wikifunctions.org/wiki/Z25266>
- date before (Z25271) <https://www.wikifunctions.org/wiki/Z25271>
- later date (Z25276) <https://www.wikifunctions.org/wiki/Z25276>
- is proleptic? (Z25280) <https://www.wikifunctions.org/wiki/Z25280>
- identical quantity (including bounds) (Z25286)
<https://www.wikifunctions.org/wiki/Z25286>
- amount from quantity (Z25294)
<https://www.wikifunctions.org/wiki/Z25294>
- lower bound from quantity (Z25297)
<https://www.wikifunctions.org/wiki/Z25297>
- upper bound from quantity (Z25300)
<https://www.wikifunctions.org/wiki/Z25300>
- unit from quantity (Z25303) <https://www.wikifunctions.org/wiki/Z25303>
- are bounds equal to value? (Z25306)
<https://www.wikifunctions.org/wiki/Z25306>
- are bounds symmetric? (Z25310)
<https://www.wikifunctions.org/wiki/Z25310>
- rational has terminating decimal form (Z25315)
<https://www.wikifunctions.org/wiki/Z25315>
- has no prime factors other than 2 or 5 (Z25318)
<https://www.wikifunctions.org/wiki/Z25318>
- First gender-matching word from lexeme (Z25341)
<https://www.wikifunctions.org/wiki/Z25341>
A complete list of all Functions sorted by when they were created
<https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderb…>
is
available.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2025-06-06
--
Where will Abstract Content go?
We are currently running a consultation about the location of Abstract
Content for Abstract Wikipedia
<https://meta.wikimedia.org/wiki/Abstract%20Wikipedia/Location%20of%20Abstra…>.
I am extremely thankful to the many thoughtful contributions to that
consultation. I have to admit that I started with an opinion about what
would be the best answer, but in internal discussions before the
consultation I had changed my mind, and with the arguments and points
raised in the consultation, I am changing my mind again.
Today, I want to give a quick overview of my current state of thinking.
Note though that I am not making the decision alone, but that it will be a
decision by several stakeholders within the movement.
Originally, I was expecting Wikidata to be the natural host for long-form
Abstract Content. But, among other arguments, that would increase the
strain and technical challenges on Wikidata.
The only two options I currently see for long-form Abstract Content are on
Wikifunctions, or as an entirely new project. On Wikifunctions it would
have the advantage that the creation and maintenance of functions would be
located very close to the main user of these functions. With a new project
it would have the advantage of cleanly separating the content from the
technology, and the two communities could each govern themselves, with
their own rules, administrators, and processes.
One could argue that by having Abstract Content on Wikidata it would be
close to the data which is expected to be heavily used. And whereas I think
that is a good argument, the technical challenges mentioned above probably
outweigh these.
Personally, I think that we should stop thinking of the movement as 800 or
900 individual projects, but as one large project, but that’s a topic for a
different time. Shoutout to the stewards, global sysops, and other
cross-wiki supporters for their difficult and important global work!
In addition to the repository of long-form Abstract Content, we will also
help the Wikidata team introduce Wikifunctions references as a data type on
Wikidata. This means that new properties can be created that point to a
Wikifunctions object (put simply, Wikidata properties can have ZIDs as
values). This will allow for a lot of flexibility in the future and pave
the way for Abstract Descriptions, Abstract Glosses, or complex values and
multilingual notes.
In short: I think that it’s going to be either a new wiki or a new
namespace on Wikifunctions. Both of these would be accompanied with a new
datatype for Wikifunctions objects on Wikidata for use there.
As a reminder on the process: we will be closing the consultation next
week. Everyone is still invited to add further arguments afterwards, but we
won’t be actively tracking and following the page after that point, and
anything that comes in later might be missed when considering the answer.
We aim to come to a conclusion in the next few weeks, after the
consultation period ends, and then to create a plan in the following
quarter on how to implement the decision, and finally to implement that
plan in the following quarters.
I want to express my gratitude to everyone who has contributed to this
process so far, and I am looking forward to the comments in the final week
of the consultation! Thank you!
*P.S.:* I understand that the consultation was not as multi-lingual as some
have hoped for. We have heard your concerns. It was my decision to reach
out to all projects, although we had inadequate translation coverage. We
received some great input from members of smaller projects, for which I am
thankful for. Note that this process isn’t a vote, and thus the goal is not
to have full representation, but rather a consultation, and the idea is to
hear many different arguments and ideas in order to help with the
decision-making. Other consultations, votes, and Requests for Comments
might have different requirements with regards to a multi-lingual outreach.
Recent Changes in the software
Last week was one of our once-every-two-months regular "Fix It Weeks",
where we dedicate the team's time to fixing architectural issues, technical
debt, and minor bugs we've noticed during development, though we also made
some progress on Quarterly work.
We have made more progress on the light-weight enum work (T390558
<https://phabricator.wikimedia.org/T390558>). We have re-built our internal
Object search API to allow complex Type and return Type combinations (
T394712 <https://phabricator.wikimedia.org/T394712>), and changed how we
store details of what Objects' Type and return Type are, to allow us to
model the lightweight enum Type-returning Function (T391915
<https://phabricator.wikimedia.org/T391915>).
We fixed a tricky bug in our visual editor code noticed during the
Hackathon last month that meant that checking the visual diff of your edit
after making a change to an embedded Function call would delete it from the
page (T393319 <https://phabricator.wikimedia.org/T393319>). We also fixed a
bug in new, not-yet-deployed code that meant that the language dialog no
longer searched for languages correctly (T395469
<https://phabricator.wikimedia.org/T395469>).
We changed our visual editor integration code to consistently emit field
updates on changes, rather than only in validation states, to allow any
other forms of change to be consistent (T395540
<https://phabricator.wikimedia.org/T395540>). We also unified the styling
of the "chips" for embedded Function call fragments, so they don't have
different appearance or cause jumps when transitioning (T395547
<https://phabricator.wikimedia.org/T395547>).
We have fixed a series of issues related to font size, found as part of
preparing for the upstream change of these in Codex last month. This
includes in the accordion in the Function Metadata dialog (T392703
<https://phabricator.wikimedia.org/T392703>), in the Function report's
icons on Implementation and Test case pages (T392707
<https://phabricator.wikimedia.org/T392707>), in the code editor (T392711
<https://phabricator.wikimedia.org/T392711>), in the expanded toggle
control in complex Objects (T392704
<https://phabricator.wikimedia.org/T392704>), in the Function call
component's icon sizes for the Function call, argument references, and
Wikidata entities (T392706 <https://phabricator.wikimedia.org/T392706>), in
the "empty" bubble for the language of a ZMonoLingualString component (
T392700 <https://phabricator.wikimedia.org/T392700>), in Type converters'
empty states, and in a number of other areas we noticed that didn't have
individual tasks.
We replaced our use of the mw.Uri utility with the browser-native URL API (
T394820 <https://phabricator.wikimedia.org/T394820>), as our part of
Wikimedia-wide work to deprecate the utility.
We've re-factored the code around the code that handles embedded
Wikifunctions calls in wikitext, to move most of the cache access code into
the isolated database access code, for easier reasoning and testing. We
consolidated some of our code around publishing Implementation code, to
avoid repeating ourselves and so any future feature changes or bug fixes
will need to be done only once (T357696
<https://phabricator.wikimedia.org/T357696>). We also switched our uses of
HTTP status codes out for a set of constants, for consistency (T394746
<https://phabricator.wikimedia.org/T394746>).
We, along with all Wikimedia-deployed code, are now using the latest
version of the Codex UX library, v2.0.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.
Recording of presentation at Wikidata and Sister Project
The recording of the presentation *Wikifunctions: how Wikidata powers
language functions (and beyond) <https://www.youtube.com/live/7oKb0DoYEag>*
by David Martin <https://www.wikifunctions.org/wiki/User:DMartin_(WMF)>
and Luca Martinelli <https://www.wikifunctions.org/wiki/User:Sannita_(WMF)> at
the Wikidata and Sister Projects event
<https://www.wikidata.org/wiki/Event:Wikidata%20and%20Sister%20Projects> is
now available on YouTube <https://www.youtube.com/live/7oKb0DoYEag>.
Recording of last Volunteers’ Corner available
The recording of Monday’s Volunteers’ Corner
<https://commons.wikimedia.org/wiki/File:Abstract%20Wikipedia%20Volunteer%20…>
is
now available on Wikimedia Commons. We thank all volunteers who joined us,
and wish you happy watching!
Fresh Functions weekly: 14 new Functions
This week we had 14 new functions. Here is a sample of the new functions
with implementations and passing tests to get a taste of what functions
have been created. Thanks everybody for contributing!
- Gregorian date as string to Dagbani calendar date (Z24876)
<https://www.wikifunctions.org/wiki/Z24876>
- Gregorian date to Dagbani calendar date (Z24880)
<https://www.wikifunctions.org/wiki/Z24880>
- Gregorian calendar date identity (Z24884)
<https://www.wikifunctions.org/wiki/Z24884>
- map to natural number (Z24846)
<https://www.wikifunctions.org/wiki/Z24846>
- filter list for natural numbers (Z24849)
<https://www.wikifunctions.org/wiki/Z24849>
- time between two dates with unit in English (Z24901)
<https://www.wikifunctions.org/wiki/Z24901>
A complete list of all functions sorted by when they were created
<https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&orderb…>
is
available.
_(cropped).jpg){kind=link}