Change Details

Wikidata search is generally configured to blend two search engine implementations: * EntityIdSearchHelper to match entity IDs using the main database * CirrusSearch to allow more complex matching CirrusSearch can match entity ids but we still rely on EntityIdSearchHelper to mitigate the impact of the search update lag which in some workflow can be annoying: * create an entity * copy-paste the ID * search for this ID in another drop-down (i.e. setting a statement value on another entity) EntityIdSearchHelper is primarly designed to work on items and will extract some metadata useful for the UI and/or API consumers. Unfortunately for Lexemes these metadata is not that helpful and we should adapt/customize EntityIdSearchHelper for the Lexeme use-case. See T405475 for more context about what metadata should be extracted.

Wikidata search is generally configured to blend two search engine implementations: * EntityIdSearchHelper to match entity IDs using the main database * CirrusSearch to allow more complex matching CirrusSearch can match entity ids but we still rely on EntityIdSearchHelper to mitigate the impact of the search update lag which in some workflow can be annoying: * create an entity * copy-paste the ID * search for this ID in another drop-down (i.e. setting a statement value on another entity) EntityIdSearchHelper is primarly designed to work on items and will extract some metadata useful for the UI and/or API consumers. Unfortunately for Lexemes these metadata are not that helpful and only the lexeme ID might be shown, we should adapt/customize EntityIdSearchHelper for the Lexeme use-case and present the lemma, with its lexical category and language. See T405475 for more context about what metadata should be extracted.

Wikidata search is generally configured to blend two search engine implementations: * EntityIdSearchHelper to match entity IDs using the main database * CirrusSearch to allow more complex matching CirrusSearch can match entity ids but we still rely on EntityIdSearchHelper to mitigate the impact of the search update lag which in some workflow can be annoying: * create an entity * copy-paste the ID * search for this ID in another drop-down (i.e. setting a statement value on another entity) EntityIdSearchHelper is primarly designed to work on items and will extract some metadata useful for the UI and/or API consumers. Unfortunately for Lexemes these metadata isare not that helpful and only the lexeme ID might be shown, we should adapt/customize EntityIdSearchHelper for the Lexeme use-case and present the lemma, with its lexical category and language. See T405475 for more context about what metadata should be extracted.