Wikifunctions:Status updates/2024-07-03
◀ | ![]() ![]() |
▶ |
Wikimedia Foundation annual plan
The Wikimedia Foundation recently announced its Annual Plan for the 2024/2025 financial year, which started this week and will end on 30 June 2025. If you’re interested in what the Foundation is up to, you can find it described in a lot of detail there. This includes the work we will be doing on Wikifunctions and Abstract Wikipedia.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Wikimedia_Foundation_Annual_Plan_2024-2025_Header_Image.png/220px-Wikimedia_Foundation_Annual_Plan_2024-2025_Header_Image.png)
The work on Abstract Wikipedia is part of the Product & Technology department. The Objectives and Key Results (OKRs) of the Product & Technology department are also published as part of the annual plan. We are part of the Wiki Experiences objective around Encyclopedic content (WE2). Our work will fall under the following key result (WE2.4):
“By the end of Q2, enable Wikifunctions calls on at least one smaller language Wikipedia to provide a more scalable way to seed new content.”
Context: “To reduce our knowledge gaps effectively, we need to improve workflows that support scalable growth in quality content, especially in smaller language communities.”
This is further broken down into three Hypotheses that will guide our work (WE2.4.1–WE2.4.3) in the first Quarter of the financial year. You can find these in the list of Hypotheses:
- "If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2" (T261472)
- "If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1" (T363391)
- "If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful" (T282926)
Hypotheses will be formed throughout the year, in order to actively plan work on a quarterly cadence based on our progress and things we learn. The next section shows the work we’ve planned for testing the above Q1 hypotheses, plus additional projects we think are important for supporting the themes of our strategic goals.
Quarterly planning
As we did the previous Quarter and the Quarter before, we are publishing our plan for the Quarter that just started. And, as you can see by the publication dates of our plans, we are getting better at planning in a timely manner.
For the upcoming three months, we are planning to work on:
- Prototype Wikifunctions calls in MediaWiki: We will have a prototype implementation that will allow function calls embedded in the wikitext of a MediaWiki page, and the result of that function call will be displayed when reading the page. We do not plan to deploy this prototype on a production wiki in this Quarter, but it will prepare us for the next.
- Design prototype for Wikifunctions use case in Wikipedias: We will create and publish designs on how Wikipedia contributors can embed function calls while editing Wikipedia.
- Enable access to Wikidata content from Wikifunctions: We will enable the Wikifunctions community to access Lexicographic Forms of a given Lexeme, and thus to get irregular forms from Wikidata. This will make it possible to construct grammatically correct sentence fragments using Wikifunctions.
- Performance improvements: Currently, Wikifunctions has noticeable performance issues. We will spend time on understanding the issues better, and deploy at least one significant performance improvement.
- Production monitoring logging: We will improve the logging on Wikifunctions. This will help us with fixing issues, particularly with regards to performance.
- Internal roadshow demoing WF and talking about AW: We will be presenting internally about Wikifunctions and Abstract Wikipedia, with the goal of having more people at the Foundation better understand what we are doing.
- Improve About widget experience for translators and multilingual contributors: We have shared designs for improving the About widget, particularly with regards to improving multilinguality on Wikifunctions. We will integrate community feedback and implement the design.
- Testing Wikifunctions Services with Catalyst: We want to improve the testing of Wikifunctions, in order to find issues sooner and confidently continue development of new features. We will work with the Quality and Test Engineering team to reach that goal.
- Design outline for HTML output: We will capture the team’s developing shared understanding on how in the future we might go beyond raw text output in Wikifunctions, written up in a document. This will guide work in the following quarters.
An overview of this Quarter’s work can be seen in a brand new Phabricator board. (Almost) all the tasks listed above are represented in the column “Epics for this Quarter”.
Current issues on Wikifunctions
We currently experience a lot of issues running functions on Wikifunctions. We are investigating. The main task in Phabricator to follow our work is T368892. We apologise for the inconvenience. Because of the US holiday and other schedule issues, we do not expect the situation to be resolved quickly, but expect issues to continue at least into next week. We still have not uncovered the root cause of the current problems, which makes predictions of when it will be resolved challenging. Thank you for understanding.
Recent Changes in the software
Last week we finished off the Quarter (and Wikimedia Foundation fiscal year) by fixing a few loose ends and preparing for this week's start of a new Quarter.
As a small, but hopefully valuable, quality-of-life improvement, you can now press "Ctrl"+"↵" (or "⌘"+"↵" on a Mac) when writing in the edit summary field to trigger publication (T348182). If you press just the Enter key ("↵"), you will be reminded of the feature in a message. This is the same shortcut and notice as used in the visual editor, the 2017 wikitext editor, and other places.
When you try to publish changes to a Function definition as a Functioneer, we show a big warning that this will likely break all the attached Test cases and Implementations. However, if your Function doesn't yet have any, we now don't show that warning to you, as there's nothing to break (T326548). If the system has an error when running a function that's caught in the middleware, such as a back-end service being down, we now show an error message to you rather than a mysterious blank space (T314267) and don't crash the widget (T361683), and emit a better error from the middleware in the first place (T368531).
The tables of Implementations and Test cases on Functions will now update the numbers in the pager counter when you expand to all items (T362587). When you approve or deactivate an Implementation or Test case, we now add a basic edit summary (T303430). This is not yet internationalised (so whatever language you read and edit in, the history page will show the message in English), and you cannot add any comments of your own (such as "this is a great second example of how to do this in JS but is slow so won't be used"); those features may come later.
We simplified how we monitor use of the function-calling API to capture "inline" definitions of Functions and their Implementations, as used for example when running Test cases or trying out a specific Implementation (T356228 and T360369). We upgraded our JavaScript code auto-documentation to the latest version of the Wikimedia-wide standard template, v1.1.0, alongside other teams (T368081).
We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.8.0, as of this week. It should have no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue.
We are excited for our transition from Minerva to the highly responsive Vector-2022 as the new mobile skin, scheduled for early next week. This update aims to enhance user experience, ensuring a more welcoming and intuitive interface for readers, while maintaining the functionality that our current editors rely on.
Volunteers’ Corner on 8 July 2024
Next week, on Monday, 8th July 2024, at 17:30 UTC, we will have our monthly Volunteers’ Corner. We are sorry for postponing it at the last minute from this to next week, due to several people on the team being unavailable.
Unless attendees have many questions, we will follow our usual agenda of giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together. Looking forward to seeing you on Monday!
Reminder: Input needed for design proposal towards better multi-linguality of the About widget
During this Quarter, we’ve been working on improving the experience of use for multi-lingual readers and editors. We started a page for designs on Wikifunctions, that also hosts this particular design.
We'd love to hear your thoughts about this proposal. Feel free to leave any feedback on the Discussion page. Thank you to the community members who have already given feedback, there and elsewhere.
Function of the Week: get total count of a given day in a specific month and year
![](http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Lunar_Year_of_Rabbit_Water_in_Manila_40.jpg/220px-Lunar_Year_of_Rabbit_Water_in_Manila_40.jpg)
Have you ever wondered how many Sundays there will be next July? Now, there’s an app for that! I mean… a Function on Wikifunctions!
The Function count a day of the week in a month (Z17452) takes three arguments:
- A day of the week
- A Gregorian calendar month
- A natural number representing the year
The function then returns a Natural number that tells you how many of the selected days of the week have or will occur in the given month and year.
For example, looking at the given picture taken in Manila of a calendar page for January 2023, we can see that there have been five Sundays. If we ask the Function and enter Sunday, January, and 2023, it returns 5, as expected.
The Function currently has three tests:
- that there are 5 Thursdays in February 2024
- that there are 4 Saturdays in February 2022
- that there are 4 Wednesdays in February 2023
And it has a single Implementation, written in JavaScript. The Implementation uses JavaScript’s built-in Date class to iterate through each day of the given month, check whether it is the day we are looking for, and counting those.
I really like the scope of the Function, going well beyond what standard libraries usually offer.