Wikifunctions:Status updates/2024-07-18
◀ | ![]() ![]() |
▶ |
Research report on integrating Wikifunctions from Wikipedia
![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/a0/Research_report_WF_to_Wikipedia.png/220px-Research_report_WF_to_Wikipedia.png)
Over the last few months, we engaged with a design researcher to find answers to the following two questions:
- What opportunities exist for improving the workflows and effectiveness of Wikipedia contributors through Wikifunctions?
- What barriers to a successful Wikifunctions integration might exist?
We have now published the report on Wikimedia Commons.
Our researcher found that the typical contribution workflows described by small language Wikipedia editors primarily involve translating articles from larger Wikipedias (usually English) to their own language using tools like the Content Translation Tool. They also engage in expanding articles, correcting errors, and fixing technical issues (e.g. templates). The major technical issue highlighted by participants is the lack of corresponding templates when translating articles, particularly from English. This often leads to content omissions, errors, or missing references when articles are created in these ways.
There is a notable shortage of technical knowledge within many Wikimedia communities, with a few experienced editors often handling most technical tasks. A good description of such a situation can be found in a recent Signpost article about the Russian Wikipedia community.
As the communities and their content grows, the sets of templates on different language Wikipedia editions tend to become more complex, and more different from other wikis. Smaller Wikipedias often start with templates copied from English Wikipedia, but then evolve them according to their own needs and policies. The research did not find specific details on regular processes followed by communities to maintain template code and Lua modules.
The research found that updating facts in articles isn’t a common workflow among participants. Their focus is generally on creating new articles, rather than keeping existing ones updated. However, some contributors use automated tools (e.g. "databoxes") for streamlining content from sources like census data via Wikidata.
Most participants had heard of Wikidata and Wikifunctions, and they were generally positive about these projects. Familiarity with Abstract Wikipedia was lower, but participants who knew about Wikifunctions viewed it positively, and understood its future potential to support their work. Participants generally reacted positively to a Wikifunctions integration mock-up demonstrated in a video. They quickly grasped the value proposition of Wikifunctions.
Some participants mistakenly believed that any text produced by Wikifunctions or Abstract Wikipedia would be machine-translated from English, and there was confusion about the distinction between machine translation and structured data-driven text generation. Clarification was also needed that functions would not be hosted and maintained on their own language Wikipedia, but could be used across languages.
The research report provides the following recommendations:
- Integrate Wikifunctions into common activities that editors are motivated to perform, and are already familiar with.
- Adapt Wikifunctions to solve existing technical challenges, to achieve a net reduction in the overall technical burden facing editors.
This includes creating functions that replicate the functionality of frequently used, existing templates or modules on English Wikipedia, and to make functions available for contributors to use on other wikis with little or no effort. We also should ensure that the Wikifunctions integration supports diverse, wiki-specific editorial policies.
The report focused on editing patterns for Wikipedias, but we hope that the insights will be generalizable to all our projects. Thanks to Andrew for creating the report, Amin for supporting Andrew and for creating much of the wording used in the above summary, Amy and Bethany for shepherding the report, and to the many community members who have been interviewed and whose insights contributed to the report.
You can read the full report on Wikimedia Commons.
Recent Changes in the software
This week, a fair bit of our energy has gone into the Quarterly planned work, especially around logging in the back-end services (T368000), which we've deployed this week.
We've changed the algorithm that selects the fastest Implementation (and re-sorts the list on-wiki), to reduce some confusion. Previously it used the total server CPU time, but now it will use the server-side duration ('wall time'). This may select code that runs slower on our servers, but in practice runs faster for users (T369587).
We've improved the logic in the front-end when editing the type of typed lists; instead of removing all items when you changed their type, we now only remove non-matching items (T352258). This means that if you had a Typed list of general (Object (Z1)) Objects, half of which were Strings (Z6s) and the other half Booleans (Z40s), and you changed it to be a Typed list of Strings, the Booleans would be dropped but the Strings would remain.
We also landed a pair of quality-of-life improvements in the front-end experience. First, we changed the <title> to be simpler: instead of "{Label} {ZID} {Type} - Wikifunctions" (e.g. "Echo Z801 Function - Wikifunctions") to just "{Label} - Wikifunctions" (i.e. "Echo - Wikifunctions"). This is how Wikidata behaves, and we hope will make tabs quicker and simpler to read (T360169). Second, we changed the old design of the h1 heading on Object pages, which previously followed Wikidata's design. We have switched the ZID from being in parentheses to being in monospaced font, and copyable on click, to be consistent with the "function explorer" widget (T360001). This is a behaviour that Wikidata might want to copy from us! 😉
We've fixed a bug that meant clicking the "Jump to content" link that MediaWiki inserts into the page would delete labels when creating new Functions or Objects in Chrome (T348094).
We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.9.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.
New type: Gregorian era
We created an enumeration for the Gregorian era, as there was support expressed for that by the community on the Type proposal. It has two values: one for the era we are in, and one for before. They are currently named AD and BC in (international) English, and CE and BCE in American English – but we are a bit unsure about the naming, and as always defer to the community to select the names they find most appropriate.
The related proposals for day of the Roman year, Gregorian year, and Gregorian calendar date have not seen much interaction yet, and it would be great to see feedback, or alternative proposals. Maybe splitting the proposals up into individual pages made it hard to navigate and review?
Based on that experience, we put the Wikidata lexeme related types on a single page, as discussed last week. That saw quite a bit of interaction, and we went ahead with setting up prototypes of the structure of the Types on wiki. We also added the Lexeme sense Type, but that needs to be drafted further. We ask for these Types to not be used yet (and probably for a while), while we figure out how they can be connected to Wikidata. We will keep you updated.
Denny out(ish) for a few weeks
Denny will be moving from the USA to Germany in the next few weeks, and thus be less available. As last time, Sharvani will take over the weekly newsletter.
A freely-editable presentation about Wikifunctions & Abstract Wikipedia is available
During last quarter (April to June 2024), we worked to produce a basic presentation about Wikifunctions and Abstract Wikipedia that could be freely reusable and editable by you users, in case you were thinking of holding a presentation about our project(s) but needed some help with it.
We're happy to say that version 1.0 of the slidedeck is now freely available and downloadable. Feel free to download it in the format you like and translate it or modify it to your liking. You can also comment on slides, if you want to give us feedback or you need clarifications. You can also use the thread at the Project chat for this, if you want. We'd love to see what changes you make, and any final presentations (in any language) if you use them.
Also, be aware that most of the slides have speaker notes: we did it to allow people to better understand what was the idea behind the introduction and most of the image-only slides. Notes are also freely reusable, modifiable and translatable, of course.
Unfortunately, since Commons doesn't allow us to upload .odp or .ppt files, we can only host it on Google Docs for the time being. We know this could be a problem for some of you, so if you need a copy of the slidedeck in an open format, please email User:Sannita (WMF), and he will send it to you. Thanks for your patience!
Function of the Week: Divisors
Last week, we announced that typed lists are now available to work with on-wiki defined types as well. We now have quite a number of functions working on typed lists. So we chose a Function that deals with such a typed list: divisors (Z13726).
A divisor is a number that divides a given number without a remainder. We have a Function, is divisible (Z13740), which checks whether a number is divisible by the other. For example, 6 is divisible by 3, and 24 is divisible by 8, but neither of them would be divisible by 7.
The divisors (Z13726) function takes a natural number and returns all the numbers that the given number is divisible by, as a typed list of natural numbers. For the input 6, this would be 1, 2, 3 and 6. For 24 that’s the list 1, 2, 3, 4, 6, 8, 12, and 24. For 7 that’s just 1 and 7, which means that 7 is a prime number as it is divisible only by 1 and itself.
The function currently has three implementations:
- one in Python, that checks the values until the square root of the argument
- Another in Python, that checks all the values until the argument
- And one in JavaScript, that also checks all values until the argument
The Function has seven tests, checking for the divisors of zero, six, nine, ten, sixteen, seventeen, and Belphegor’s prime number. That’s quite a nice spread: zero tests for an edge case (the other edge case, one, is missing), seventeen for a prime, nine and sixteen as cubic and quartic numbers check for repetitions of the factors, which could happen in some implementations. Six and ten are nice, usual values. And Belphegor’s prime is to stress-test the implementations, being a very large prime number, and as expected, the implementations time out (and accordingly, this test is not connected)
Note that we currently do not support code implementations for functions with untyped lists (T370028).