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

Proposed design

Edge cases

lexeme does not have senses

Notify the user and still allow them to select it and if they do, show them the CTA to add to wikidata hyperlinked to the Lexeme page

@DSmit-WMF can we know before lexeme selection whether they have senses or not?

In T341069#10984799, @Jdforrester-WMF wrote:

Is Amin's design sketch above the final, agreed version? There haven't been any updates here, but maybe somewhere else?

Lexeme Sense selection UI design exploration
I understand that Lexemes and sense are not exactly the same thing as words and definitions, permit me to use them interchangeably. When a word has multiple definitions and you want to find it, you will first of all think of the word then think of the definitions like in the dictionary. Also definitions/senses are phrases or sentences and not 1 word so it is going to be more difficult to search directly for them. As a result, a direct search for lexeme senses may not be the best experience.

Proposed design