✨ อัปเดตล่าสุด: wiki/Special:MyLanguage/Wikifunctions:Status updates/

Wikifunctions Status updates

Errors and fallbacks in Abstract Wikipedia

As we start working with pilot communities to pick the first articles to show to readers, some key questions about errors and fallbacks on Abstract Wikipedia have come up.

How do we serve both contributors and readers well? When a Function call can’t render part of an article, contributors need to see the gap so they can fix it. Pilot communities deciding on whether to show readers an article need it to look finished to their readers. So, the same error or call to action that helps a contributor can make the article look unfinished to readers.

This leads to a second question: apart from the quality of its content, how does someone know when an article is ready for showing to readers? We don’t have a mechanism for deciding or showing this yet, and would like to open up the discussion on how we could handle this.

Today, there are four ways a Function call can behave when it can’t produce the expected result:

It may raise an error, and display a red box with a message supplied by the community, hopefully giving a hint on how to fix the error, e.g. the Item that does not have a Lexeme in the right language.
It may display a fallback rendering, capturing in some way what should have been displayed, and often with a link and a call to action. This can be some abstract notation borrowed from mathematics, QIDs, and often some noticeable colors.
It may use the all-or-nothing rich text block (Z44729) Function which, in case the rendering returns a result, shows the results, and in case it raises an error, doesn’t show anything at all.
It may silently ignore inputs and use a different language to the one requested, as decided by the Function's authors. This might be good enough generally but not in some edge cases, e.g. you ask for Swiss French and you get international French, and the idioms / vocabulary are different for this specific topic.

Now there are (at least) two competing wishes about what should happen when a Function cannot do its job:

It should invite potential contributors to fix the issue
It should either get out of the way and let readers read the rest of the article without looking broken, or it should tell us that this article would be missing crucial information and should not be rendered

The different solutions fulfill these requirements sometimes more, sometimes less:

An error stops an article from being counted as an article available in the given language and invites the community to fix it up. We could use this information to block displaying these articles to readers (but do not do so currently).
A fallback rendering displays as text, making it (for a computer) difficult to distinguish from a successful rendering. The system cannot know that this is not an article that works, and so it cannot e.g. block displaying that article to readers. The text invites the community to fix it up.
Making a Function call optional does not block the article from being counted as a successfully rendered article, nor does it block showing to readers. But there is no indication that anything is missing, thus failing to invite the community to fix the Function call.

We see that all three solutions are lacking. We would like to invite the community to discuss possible ways forward, and to decide together on what to do.

A first suggestion could be:

Block communities from showing articles to readers if they currently raise any errors in that language.
Extend the optional Function with the ability to carry metadata (a notice, or a warning) which is collected and displayed on request, in order to continue to have the calls to action available, and still allow for a clean reading experience.
Retire fallbacks for either errors or optionals.

One open question is also how to deal with reader-displayed articles that had no errors when they were initially shown, but produce errors now. One possibility would be to just remove the display, another could be to freeze the content and not render a new version until it renders without errors.

Another alternative that is being discussed by the community is to extend the configuration type to carry explicit information about fallbacks.

Let us know what you think! We will be following the IRC / Telegram chat and the talk page of this newsletter for a discussion.

Recent Changes in the software

This week we delivered a number of improvements to Wikifunctions, disrupted from last week due to the PHP security update.

In the Details view, we now show the number of sub-calls made (T440238). The display of the duration and other meta-data in the "Details" dialog should also now be better in RTL, though it is not (yet) translatable (T372704). We’ve also made several display fixes. Argument references no longer sometimes display incorrectly in the collapsed view, as they did on Z17290 (T368320). Very long values, like those on Z21409, now wrap instead of stretching off the page (T407594). We also no longer prompt you to “Run with latest data” on a Test case result, since that didn’t work there (T441305).

For type conversion, we now support type_convert_to_code / type_convert_from_code and typeConvertToCode / typeConvertFromCode functions in the executors. This will allow community-defined type-conversion functions to call default type conversion logic, reducing the complexity of type conversion and paving the way for full type-converter reuse.

Finally, we created on the back-end a set of Map/Filter/Apply functions to apply functions with arbitrary argument signatures, which expands the flexibility of functional primitives, allowing these functions to be applied to functions with arbitrary argument structures; the community has shored up this weakness with compositions, but a built-in function will be a bit more efficient and easier for the AW team to support. Due to the security disruption, these will be added onto Wikifunctions.org next week.

Next Volunteers’ Corner on November 9 at 11 UTC

The next Volunteers’ Corner will be on Monday, 9 November 2026 at 11:00 UTC. Note the earlier time in the day, in order to make it easier for some folks to attend this one. We plan to have the following agenda: there will be time to ask questions and discuss all matters arising. If we have time, we will write a function together. Everyone is welcome to join us on Google Meet.

Fresh Functions weekly: 182 new Functions

This week we had 182 new functions! Here is an incomplete 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.