Change 323503 had a related patch set uploaded (by Santhosh):
Use mw.widgets.TitleInputWidget for page selector

https://gerrit.wikimedia.org/r/323503

Screenshot

Graphical changes from previous version that either needs to be fixed or approved by Pau:

1. Horizontal scrollbar
2. Description truncated
3. The page names are links, which can be opened with right click, and they go to the wrong wiki
4. Instead of showing ~6 results, it now shows as many as fits the screen vertically

Niklas, The scrollbar strangely disappears once you hover on the selector.

https://en.wikipedia.org/wiki/m?redirects=no page exist.

About that and other comments. I would like to have less deviation from the original MW core widget for title search and look up. Otherwise it will defeat the purpose of using a common shared widget than one written inside CX. @Pginer-WMF please comment.

m does exist, but it is exactly the same article as M. Makes no sense to show it twice.

In T151985#2879301, @santhosh wrote:

About that and other comments. I would like to have less deviation from the original MW core widget for title search and look up. Otherwise it will defeat the purpose of using a common shared widget than one written inside CX. @Pginer-WMF please comment.

I'm not sure I have enough context to comment about. I think it makes sense to align article selection controllers with the standard. However, it also makes sense to (a) improve the standard when it falls short and (b) customise it to specific contexts when it makes sense.

For example, we can take T111094 as the reference of the proposed direction for the CX article selection, and either the selector on wikipedia.org or the link selector on VE as the selectors representing the standard (which are already different from each other, which I reported at T153417). Comparing those, I think that:

• It is ok to adopt the layout and colors of the standard. If we think a better layout is possible, it makes sense to propose as a general improvement for the standard. The wikipedia portal and VE versions of the standard also differ in the colors and whether to use lines to separate each item.
• It is ok to adopt the way the standard highlights matching part of the title as the user types it (either underlying as the portal or making it bold as in VE). If we think a better way of highlighting is possible, it makes sense to propose it as a general improvement for the standard.
• In our context it makes sense to surface the number of languages an article is available in, and whether it is missing on the user selected target language. This is information that we identified from research that is helpful for translators. This is not useful for a general purpose selector, but it makes sense to extend the default in our context. The general component should be extensible for these kind of customisations, and making it that way if it is not already would be helpful.
• It also makes sense to customise the next step after selecting the article. When an article is selected, the input field is expected to be replaced by the selected item (similar to what happens with the link selector in VE). Currently it just replaces the text making it unclear whether the selection happened.

Hope this helps.

In T151985#2879967, @Pginer-WMF wrote:

I'm not sure I have enough context to comment about.

@Pginer-WMF Specifically, does the thing we have now proposed in the patch (in the photo below), look acceptable, or what should be changed, in your opinion, before the patch can be merged?

To me there are obvious changes, in order of severity based on my opinion:

1. Horizontal scrollbar (apparently not in all browsers, goes away on hover)
2. Mysterious first item appearing on some input with no photo or description, duplicating some other item
3. Description is truncated instead of wrapped
4. Instead of showing ~6 results, it now shows as many as fits the screen vertically
5. The page names are links, which can be opened (with right click context menu or middle mouse button only; left click selects the item)

Mysterious first item appearing on some input with no photo or description, duplicating some other item

I dont know from where this comes. It is a redirection page in wiki. Happens in VE also

Instead of showing ~6 results, it now shows as many as fits the screen vertically

Not exactly correct. 10 items. Default is 10 as defined by widget.

In T151985#2889337, @Nikerabbit wrote:

@Pginer-WMF Specifically, does the thing we have now proposed in the patch (in the photo below), look acceptable, or what should be changed, in your opinion, before the patch can be merged?

I agree with most of your analysis. Here is my take on these:

The most important issues:

1. Horizontal scrollbar (apparently not in all browsers, goes away on hover)

This adds unnecessary clutter and distracts from the intended pattern of a vertical list.

2. Mysterious first item appearing on some input with no photo or description, duplicating some other item

I'm not sure which are the consequences of adding such item, but if it is not an article it does not make sense to show it and even less showing prominently as the first item.

4. Instead of showing ~6 results, it now shows as many as fits the screen vertically

I think the list should have a max-height value. Users can access more items by scrolling.
this seems to be the case of the link inspector in VE.

Less relevant or subject to discussion:

3. Description is truncated instead of wrapped

Both approaches have pros and cons. Truncation allow for items to have the same structure making it fast to scan vertically; while wrapping provides all the details. Given that the purpose of the description is to disambiguate, we just need enough of it to be visible for that purpose. I surfaced the inconsistency in T153417, for a general decision to be made for the standard component.

Regardless of the approach, we may want to adjust the selector width and the font size to make sure that most descriptions will fit in one line. The VE link inspector seems to use both a smaller font and a wider panel, making it less common to find items with descriptions too long to be cropped.

5. The page names are links, which can be opened (with right click context menu or middle mouse button only; left click selects the item)

Opening the article to check it before translating was a need we identify from user research. the use of right-click here is not the most convenient way to support that. In T111094, we are providing an explicit way to open the article after you select it. However, we can live with it as a workaround for now, until T111094 is supported.

In T151985#2889384, @santhosh wrote:

Mysterious first item appearing on some input with no photo or description, duplicating some other item

I dont know from where this comes. It is a redirection page in wiki. Happens in VE also

It is not a redirect (a page with #REDIRECT mark-up). MediaWiki normalizes to M, which is a page. I guess VE allows to link to non-existing pages, which is the reason it is there. But we only allow existing pages.

So after further investigation, I filed a bug for the main issue: T157672: Bogus horizontal scrollbar in OO.ui.mixin.LookupElement
The other issues don't block merging, as far as I gather from the comments. And even the main issue only happens under certain conditions, which only some small set of users would encounter, so I am going to merge this patch.

Change 323503 merged by jenkins-bot:
Use mw.widgets.TitleInputWidget for page selector

https://gerrit.wikimedia.org/r/323503

Verified in production.