More detail will be useful but we should also cater for new contributors (in particular) by providing a call-to-action for any error result.

This was mentioned on Telegram (in my reply to @Sannita):

I suppose… but they are invisible to the community unless they make an edit somewhere. I don’t think we’re terrible at helping people who complain or ask for help. I was thinking more of a log of function calls that fail during an edit session that is not published. If we knew which functions people were trying to use, we could focus on improving those. There’s not a lot we can do if their language lacks adequate support, but maybe the default functions could generate a link to a page encouraging them to leave a comment? Or any page with an error could have such a link? This, for example, is not helpful:

“Wikifunctions returned a failed response: Could not acquire WASI runner within time limit”

…but it shouldn’t be hard to add a reporting link to the message (with a better explanation in the linked page).

I think we already have a ticket for more error detail, so I’ll link to this comment there (when I find it, which is another challenge).

Where the “reporting link” is the call-to-action.

In the specific case of falling through to a default function from a configuration, the default function could provide a semantic framing like “Stockholm • city • Sweden” with each element being labelled according to the target language and linked to the Wikidata item. I think this part can be achieved with community functions, but I haven’t tried it yet. We can then add a link for suggesting a function or even adding a test case to Wikifunctions for the function that took the default path (which I guess would be hardcoded into the default function itself). We should consider cleverer alternatives, of course.

Per Product, we want to look at this soon. Lots of decisions to make about how this would work.

This task and its comments currently cover several aspects. For now, I’m going to adjust the scope for this task to focus on improving access to more detailed error information in Abstract Wikipedia first.

We can then consider ideas from the discussion, such as reporting links or logging failed function calls, as potential follow-up work. Thanks for the suggestion!

The simplest solution for the current scope would be to display the full Wikifunctions error in Abstract Wiki as shown here:

But these error messages don't seem to communicate the solution or next steps clearly. As a follow up task we can consider having clearer error messages or a way for contributors to resolve the error.

cc @LMorgantini-WMF

Thanks @gonyeahialam! Yes, making error messages more actionable would be covered in a different task.

Chatting with @gengh, here is another potential approach:

Instead of adding more detailed error messages directly in Abstract Wikipedia, include a link in the error message (e.g. “View details on Wikifunctions”).

This link would:

• Open Wikifunctions with the same function call preloaded (similar to shareable function result links)
• Allow contributors to access full error details

Why this approach

• Keeps the Abstract Wikipedia interface simple and uncluttered
• Removes the need for users to manually recreate function calls on Wikifunctions

Thanks for the summary, @LMorgantini-WMF

I wanted to expand the approach a little bit with early and possible future steps.

The Goals:

• Provide details and guidance on how to address an error in the context of an Abstract Fragment failure.
• Provide flexibility for the community to create and translate rich text errors which contain details and can offer relevant links.

Currently:

• The error details are only available in the context of the Function Metadata dialog, in Wikifunctions, when running a function and clicking "Details"
• The error message and details are displayed using a very generic and rigid logic which:
  • Cannot include rich text or links.
  • Depends on rudimentary aggregation of different error type labels, often awkwardly written, not easily readable, and with a hardcoded structure that is not translatable.

Phased proposal:

We start with adding a link that can take the user to the current Wikifunctions detailed error information. We start thinking the best approach to implement a detailed, parametrized and rich error message display, which we can address in a future Q.

• Milestone 0 (FY26Q4): Enable easy access to the existing error details display in Wikifunctions from a failed Abstract Wikipedia fragment.
  • Complexity: low
  • Details:
    • Build a call to replicate the AW fragment, replacing the Z825 arguments with the current values causing the error (Z825K1: wikidata item, Z825K2: language selected in the preview, Z825K3: today's date)
    • Build a link to the top-most function page with call={ ...built call... } url property
    • Append link to the error message E.g. "See error details in Wikifunction" or more concise "See details", "Replicate in Wikifunctions", "Explore call"
• Milestone 1 (FY26Q4): Discuss and design a method to create, translate and display flexible and rich error messages
• Milestone 2 (FY27Q1): Implement and consume new error message display strategy from WF and clients
  • Complexity: high (depends on the strategy designed on M1)
  • Details (depends on the strategy designed on M1):
    • Implement decided approach and apply display in Wikifunctions
    • Propagate new rich error messages to consumers (e.g. Abstract Wikipedia fragment error box)
    • Create documentation and guidance material, communicate with the community, request content updates

Some proposals for M1

(NOTE: These are just some I've thought about, but if we go through with the phased approach, we shall be discussing these and more during this FY26Q4)

Option 1: Reuse hardcoded logic

• Re-use hardcoded algorithm to convert an error to a string, as described above
• Generalize this logic so that it can be used in other places, not only the FunctionMetadata dialog
• ✅ Simple, probably just a very simple refactor to make this reusable
• ❌ Lacks flexibility, all issues mentioned above

Option 2: Implement error type display functions

• New key for error types Z50K3: "display html error function", which would contain a reference to a Function/Z8 that can convert a given error to a html fragment.
• Display html error functions have the signature ( Z5/error, Z60/language ) → Z89/html fragment
• We can have a fallback Display html error function built-in that implements the same logic as described above, but allow community to create custom display html error functions for different error types
• ✅ Error display fully in the hands of the Wikifunctions community
• ✅ Great flexibility to compose the error message, anything goes
• ❌ Too much flexibility, anything goes! (e.g. the produced Z89 can have an html table, images, links, anything that our sanitizer allows)
• ❌❌ We need to involve the orchestrator to build the messages: we would call the display function whenever we want to print detailed error message. When we involve the orchestrator, another error can happen, which would obfuscate error reporting and adds danger of error loops. This is so bad I'm gonna add two crosses here.

Option 3: Implement error type i18m messages

• New key for error types Z50K3: "error message code", which would contain a string/Z6 with a i18n message code that can be parsed along with string parameters, produce html and controlled/translated by the community
• There should be some well documented agreements reg. the parameters to pass to the message parsing functions. For example, we can pass all existing error keys containing string values in key order.
  • i18n.msg( 'wikilambda-error-type-no-lexeme-form' ).params( [ ZnK1, ZnK2, ZnK3… ] ).parse()
  • in en.json: "wikilambda-error-type-no-lexeme-form": "The Lexeme $1 lacks compatible representations. [[d:$1|Add them on Wikidata]]"
• ✅ We are not involving the orchestrator, the message can be built swiftly.
• ❌ The community is not autonomous when adding new error messages, they need at least a team eng's +2 to add the key to the codebase

Update 2026-04-28:

Option 4: (Suggested by Denny) Error type contains multilingual text with parametrized text/wikitext/html

• New key for error types Z50K3: "error messages", which would contain a Z12 with the error message values for any languages:

"Z50K3": {
     "Z1K1": "Z12",
     "Z12K1": [
         "Z11",
         {
             "Z1K1": "Z11",
             "Z11K1": "Z1002",
             "Z11K2": "The Lexeme $1 lacks compatible representations. [[d:$1|Add them on Wikidata]]"
         }
     ]
 }

• These messages will be parsed using different approaches:
  • In PHP we could use ( new RawMessage( $message, $params ) )->parse()
  • In javascript we could not use mw.message, and there doesn't seem to be an alternative similar to RawMessage. We would have to manually replace $* notation with the list of parameters, and then parse the message (e.g. via the action=parse API?)
• ✅ Better integration with the function model, no overlap with mw messages
• ❌ If we want these messages to contain wikitext, we depend on parsing functions
  • ❓ These messages could be in html instead. If they need to be Z89s, we might need some multilingual html type or something similar.
• ✅ Error display fully in the hands of the Wikifunctions community
• ✅ We are not involving the orchestrator, the message can be built swiftly.

In T420747#11856952, @LMorgantini-WMF wrote:

Thanks @gonyeahialam! Yes, making error messages more actionable would be covered in a different task.

Chatting with @gengh, here is another potential approach:

Instead of adding more detailed error messages directly in Abstract Wikipedia, include a link in the error message (e.g. “View details on Wikifunctions”).

This link would:

• Open Wikifunctions with the same function call preloaded (similar to shareable function result links)
• Allow contributors to access full error details

Why this approach

• Keeps the Abstract Wikipedia interface simple and uncluttered
• Removes the need for users to manually recreate function calls on Wikifunctions

• Removes the need for users to manually recreate function calls on Wikifunctions

Would users need to manually recreate the function call on Wikifunctions if the full error message is shown on Abstract Wikipedia?

@LMorgantini-WMF Yeah, this is a good starting point. Though, it doesn’t necessarily keep Abstract Wikipedia simple if the contributor has to start on Abstract Wikipedia, go to Wikifunctions from there, click “details” to view the full error, and then go to Wikidata to fix the issue. They might not instinctively know that they should click the “details” button. We sho

If the main benefit of this approach is UI simplicity, then I’m not sure it is a good trade-off on its own. But we can start from here since we have more detailed plans to improve this later, as outlined by @gengh.

I like the proposed new error messages because they seem actionable and include direct links to the relevant pages on Wikidata.

@gonyeahialam

I like the proposed new error messages because they seem actionable and include direct links to the relevant pages on Wikidata.

Note that the error messages presented in my examples only show the possibilities, but it would be fully in the hands of the WF community to create, translate and maintain them.

Also note that I have used the wikidata Lexeme link one to highlight the feature of them being HTML, but most errors don't have a relevant page on Wikidata.

Would users need to manually recreate the function call on Wikifunctions if the full error message is shown on Abstract Wikipedia?

They might want to recreate it: as I mentioned above, not all error messages might have call to actions, and community members could benefit from exploring Wikifunctions to see other examples or understand the function better.

If the main benefit of this approach is UI simplicity, then I'm not sure it is a good trade-off

Building error messages that are clear, translatable and contain all information is not a trivial problem.

The suggestion of adding the link has these benefits:

• It's a quick and easy task that we can have up in production quite soon.
• Alleviates bit part of the current hassle to understand a failure.
  • Right now users have to do the following:
    1. ☑ Click on the top-level function ID from the failing function, which would take them to wikifunctions.
    2. ☑ Replicate by hand, level by level, the full fragment function call (this can take a very long time for even an expert user)
    3. ☑ They would have to know how to manually replace arguments that are hardcoded in the AW page (qid, language, date), each one of them being a challenge if you are not experienced.
    4. ☑ They have to click run function (considering that they did not misrepresented it in the previous point)
    5. Now, they have to click "Details" and read the error
  • With a link to the pre-configured call, the first four (and most prone to error and confusion) would be gone
• The link can still be helpful in the future, even when we have better error messages

(edited as I misread your question)

Thank you for all the discussions. I will update the ticket description to reflect the 'link/replicate on Wikifunctions' approach we aligned on. I will open a separate ticket for 'more actionable error messages' to capture the follow up ideas Geno described and to keep the scope of this ticket small and clear.