Unless you need something fixed upstream in the OOUI library, you shouldn't tag it. :-) Work like this is done under UI standardisation, which you've already tagged.

If this is to be picked up under the wikibase umbrella we should probably have a word about this. Who is the product owner in this case, where in the story life cycle is this ticket located?

In T226976#5348918, @Pablo-WMDE wrote:

If this is to be picked up under the wikibase umbrella we should probably have a word about this. Who is the product owner in this case, where in the story life cycle is this ticket located?

It's part of WikibaseClient so it should be @Lydia_Pintscher's work. I want to do it for a technical reason (T203696#5331599) but what are your concerns here?

"I want to do it" is, for all I know, not the premise under which new projects are started.
Not the least to rewrite existing subsystems solely for "technical reason"s, changing their layout in the process without UX involevement, using technology that is not in line with our technical strategy.

In T226976#5348950, @Pablo-WMDE wrote:

"I want to do it" is, for all I know, not the premise under which new projects are started.

Agreed, this is part of campsite and we might be able to pick it up next week. I already talked to Lydia and Alaa about it.

Not the least to rewrite existing subsystems solely for "technical reason"s, changing their layout in the process without UX involevement, using technology that is not in line with our technical strategy.

Sure. This is a standalone widget, making it use vue might be complex but not super hard (If I understood you correctly) I agree that I need to talk to UX before giving this a facelift.

do you want to take it as part of wikidata-bridge?

My goal was to inquire if this is worked on by us as a team - applying the process which is the result of our learnings - or in a "special mode".
If the former (fingers crossed), step 0 would probably be to convert this into an epic which describes the problem we want to solve and why, not the how.

I'd be happy to throw in my 2cts once this actually takes off.

Quick PM note as discussed with Amir: we can adapt the technology (and widget changes that come with it) but we're not spending resources on redesigning the thing. That's a whole different can of worms we're not touching atm.

Thanks @Ladsgroup, @Pablo-WMDE and @Lydia_Pintscher. Some, hopefully useful, addition:

• The thought to re-consider the said module/widget has been triggered by the discovery that on client-only (in Wikibase terms) wikis only module/frontend parts of Wikibase related to the link item widget are used, although way more JS code is being loaded, which is suboptimal from the performance perspective. This task as it was originally created might be focusing too much on the possible solution instead of the problem that lead to it. This should be made more clear, thanks again to @Ladsgroup for taking time to discuss it today IRL.
• When tackled, the issue will be worked on by Wikidata engineering team at WMDE, given (apart from the obvious fact it is Wikibase software issue) we have the best understanding of Wikibase (front-end) code, and also have the overview of the ongoing front-end development happening around Wikibase, which might become relevant factor in making decisions and choosing the implementation details
• We will step back and look at the problem we intend to solve (see my first bullet point), and define it on Phabricator more precisely. This very task is likely going to be closed as it is now, in case we decide on different path of solving the underlying issue. The issue we focus on is indeed not related to the design of the widget.

In T226976#5354318, @WMDE-leszek wrote:

Thanks @Ladsgroup, @Pablo-WMDE and @Lydia_Pintscher. Some, hopefully useful, addition:

• The thought to re-consider the said module/widget has been triggered by the discovery that on client-only (in Wikibase terms) wikis only module/frontend parts of Wikibase related to the link item widget are used, although way more JS code is being loaded, which is suboptimal from the performance perspective. This task as it was originally created might be focusing too much on the possible solution instead of the problem that lead to it. This should be made more clear, thanks again to @Ladsgroup for taking time to discuss it today IRL.

Some history, extra notes. I made this patch because when I was talking to Wikipedia community members in an event, they mentioned that this design is highly used by them and they really dislike its look (which I understand) so I made this ticket to track the issue, it had nothing to do with the performance issue at first, I didn't know that issue even exist. After a while the issue of decoupling WikibaseView and WikibaseClient came up and it seemed that the "natural" solution would be to use the mediawiki core's frontend framework (ooui) instead of repo's frontend framework (vue) to decouple client from view. So I added this task as subtask. I agree this is not the only solution and probably we can just ditch in favor of vue since it's usable in client now.

If Vue that Wikibase team uses is not server-side, shipping 60 Kb of JavaScript to users in Wikipedias for a relatively small tool in the interface is probably not great, even if that makes the developer experience a bit better.

As a user though, I want to endorse the general proposal :-)

Task Review:

1. Even though we agree the underlying tech needs to change, due to the nature of this rewrite, and the technologies involved (JQuery UI to Vue and Wikit / Codex), design changes seem inevitable.
2. As this is a task of interest again, especially for additional stakeholders, I will discuss this with @Lydia_Pintscher and @Sarai-WMDE at the soonest possible date.

After discussion with @Lydia_Pintscher it was decided to:

1. Prioritize T310259: Add option to edit interlanguage links as an option on the language selector where we will simply replace the dialog with a link back to Wikidata to edit sitelinks
2. Once we have a dedicated team to work on WikibaseClient we will ensure that this is one of the first projects they work on.