In T423441#11935889, @DSmit-WMF wrote:

Suggested AW input authoring flow:

fields	moving gif

Please approve if ok!

@DSmit-WMF I thought what determines the return type of this field is the function one level above it(if any)

In T423050#11935547, @gonyeahialam wrote:

There is also an issue with the copy:
$3 = Parent Function is not what you are defining there. You are using the selected value of the function in the selector as the name of 'This field' which is incorrect. Its just the selected value. So correct is that the 'lead paragraph' expects a function that returns html. And following on that: instead of 'join text-like[..]' this is the parent 'paragraph' function that returns html and that is why the field that has 'join text like [..] as a value should return html.
The selected value has nothing to do with a parent function.

@DSmit-WMF Oh i see my error

Fix

There is also an issue with the copy:
$3 = Parent Function is not what you are defining there. You are using the selected value of the function in the selector as the name of 'This field' which is incorrect. Its just the selected value. So correct is that the 'lead paragraph' expects a function that returns html. And following on that: instead of 'join text-like[..]' this is the parent 'paragraph' function that returns html and that is why the field that has 'join text like [..] as a value should return html.
The selected value has nothing to do with a parent function.

@DSmit-WMF Oh i see my error

In T423050#11935347, @DSmit-WMF wrote:

@DSmit-WMF As a final solution based on latest discussions, when you edit an abstract article,

The flow and design are okay @DSmit-WMF

An exploration based on the popover idea @LMorgantini-WMF
A short copy shows as helper text always with more info in a popover. The Learn more button is now 'Can't find your function

In T423050#11870839, @DSmit-WMF wrote:

1. Did we decide to do it for just HTML or are we doing it for every zreference > zobject selector  type field in abstract articles?

In that case we would get something like:
"Only functions that return $1 ($2) are shown here. If a function is missing, check its return type."
Where $1 = the translated label of 'HTML Fragment 'and $2 = the zid.

If editors encounter the same problem in this other cases then we should but we can start with functions and learn from feedback before expanding.

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

In T423050#11856715, @LMorgantini-WMF wrote:

@gengh and I discussed the options as well, some key takeaways - aligned with @gonyeahialam comments:

• Option 2/3: interesting idea, main concern: ZID search might only capture the search behaviour of more expert users and would only capture zero result searches
• Option 4: Could create too much noise in selector
• Option 1: +1 to @gonyeahialam recommendation for this.
• We explored one additional display for Option 1:

• • Downside: this does not allow for a "learn more" link option
• Additional considerations: We could potentially start by only showing this on Abstract Wikipedia so it would not impact the display on Wikifunctions. We could also consider limiting this to the html wrapper level first.

I think a good solution should do two things: explain why the function is not available in this field, and help the contributor understand what to do next. In the longer term, the ideal experience may be one where incompatibility is handled automatically in the background, for example we show all the functions and if there is any that is incompatible a compatible wrapper function will be automatically added or we show this wrapper suggestions for the contributor to add themselves with 1 click. But since we want a simple solution for now, we can look at this later.

We can implement the copy feature similar to Wikifunctions if not complex @ecarg
Here is how it could look cc @LMorgantini-WMF

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

In T342450#11415229, @DSmit-WMF wrote:

We now show the function selector in the widget when no function is selected yet. Up to check for design if this is ok or if we want to change this behaviour.

Note: What do we want to do when we both return a value and also an error? (This is officially supported by the function model, but might not actually work right now; either way, we should have a plan.)

Do you have an example of such situation? @DSmit-WMF

In T415695#11828848, @DSmit-WMF wrote:

Proposal:

Let's go with the 2nd option of showing the error

When checking/unchecking the checkbox, we should alter the "done" button and activate it or disactivated depending on whether the state is submittable, but should we validate the field as well?

@DSmit-WMF can you share screenshots or links to example Wikidata statements?

One task T402176 is still in code review @Jdforrester-WMF @DSantamaria

@gengh Regarding 1, the page will benefit if the load more button is a bit quieter because the button is going to be appearing multiple times with multiple lists and may be distracting from the content.

When is it likely to be deployed? @gengh

This will be surfaced in the date field like this (once https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1187451 is merged):

This will be surfaced in the date field like this (once https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1187451 is merged):

@gengh Thanks for working on this. I see you did V2 which is great.
It will be preferable if the links open in another page and for View all functions to link to https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue instead. But I can work with current version for the test, my suggested changes are not urgent.

In T395480#11142727, @gengh wrote:

The selected text is correctly used as input value, but when inserting the function, it's duplicated instead of being applied to the selected text:

@gengh Why do you think it may not be good trigger validation by the insert button(in addition to onblur)?
Do you think debounce (1000ms) will have less premature-validation?

Since T400268 Spike: Explore MW's SearchEngine class structure, and whether switching to it from our existing SQL LIKE pattern for label search will help can't be done within the time frame. I propose we implem,ent this solution this week:

V1	V2

This design modifies the empty state when there are no results.
V1: Users are advised to try a different query if their first query yields no result.
V2: In addition to the above, additional CTAs are shown to the user which will be helpful if the function they are looking for doesn't exist.

Additional design update

Proposed design:

Proposed flow:

1. Insert button is disabled when the input fields are empty
2. Insert button is enabled when input has been typed
3. When editor clicks on insert, validation is performed
   • if there are errors, the Insert button is disabled and the error messages are displayed inline
     • The Insert button is enabled again if changes are made to the input
   • If there are no validation errors, the output is inserted
   • The current validation on-blur is retained.
   • A progress indicator will show in the dialog header during validation triggered by the Insert button

Currently, clicking on insert immediately closes the dialog but with validation happening first in this proposal and taking some seconds we would need to communicate progress. The progress indicator in the input fields wouldn't be so noticeable since the user at that point is focused on the Insert button. What progress indicators are available for the OOUI dialog?

@gengh

@gengh So For view mode would display Lexeme senses like this:

In T398801#11033610, @DVrandecic wrote:

Re Geno's question:

In view mode, I would take the lemma of the lexeme, followed by some delimiter (a long line -- or a :), followed by the gloss or the fallback (also when it's long).

This should happen quite rarely that we will see senses in view mode.

Proposed flow: Idea 1