I think the ··· button doesn't suggest what you are going to find there, but an expanded list of languages. Also, when open, the button to close it is a left arrow. For consistency, there should be a right arrow instead of a menu (···) button. I also suggest the button to be in the upper side, and not in the lower side. Now the option to translate to other languages is in the upper side, above the interlanguage links. There seems more logical.

I have to agree with @Theklan. This does feel a bit too hidden for something so crucial for the connection between our projects.

To explain a bit the rationale: The main goal for the language selection dialog is to choose a language from those available. This is a transient action that users want to do as quick as possible to reach their destination. So we don't want to add distractions to that experience, keeping it as fluent as possible. Adding options to translate, edit links, access language settings and possibly more in the future could get in the way of the main most frequent action of selecting the language.

For those users that want to do something else related to languages, they are provided one and only one possible path to find "more options" that is always present. Thus if they want to edit the links present they only have one persistent path to find them. In other words, we don't expect that users could anticipate which are the options provided behind this menu. We expect them to think that if they expect some other action to be possible, it will be found there.

This does not exclude other more contextual ways to surface such option. For example you could consider when a page is created to surface a more prominent invite to connect the pages. However, having a persistent way connected to the list of languages that is always available can be useful.

Thanks for all the input! I've been exploring options to better convey that we provide contribution options (of different nature), access to language settings and keeping the main purpose of the selector still about picking a language. A single metaphor was not working well for all cases, so I explored to separate the access to the options to contribute to the list of languages with a separate access to language settings. In this way both paths are expected to be discoverable.

The proposal in more detail os captured in T323694: Language selector: provide separate access to options to contribute and language settings

With this approach, having the option to "Edit language links" in Wikidata becomes more important in order to provide more than one way to contribute to the list of languages (currently only translating would be available).

Thank you! I think this is a great direction. I guess this task is stalled then until T323694 is done?

In T310259#8441267, @Lydia_Pintscher wrote:

Thank you! I think this is a great direction. I guess this task is stalled then until T323694 is done?

There is no need to wait. T323694 will change how options are displayed/organized but the way an option is added to this extensible menu will not change. That is, no code changes will be needed for the "Edit language links" option to be visible in the new menu if it was added before.

However, if the option to "Edit language links" is added some time after the menu is reorganized by T323694, there will be a time when the new menu has just one option ("Translate") which is not ideal.

Quick update: code supporting the new structure for the menu (T323694) is already available. Given the review and deployment process, it may still take a week to become visible to users
It was confirmed that this update is not changing the way items are added to the menu from the code perspective. So the "Edit language links" option can be added in the usual way.

Excellent. Thanks. Adding to our sprint prep then.

The way items are added to the menu from the code perspective seems to be (based on ext.cx.entrypoints.uls.relevantlanguages.js):

• listen for the mw.uls.compact_language_links.open hook, which is called with a $trigger
• get the ULS instance from the trigger as var uls = $trigger.data( 'uls' );
• insert any DOM element(s) you want before the ULS instance’s results view, like uls.$resultsView.before( missingLanguagesPanel );

Edit: I think that last part might be slightly wrong, but looking at ContentTranslation and that hook should be a good starting point, at least.

The process to register a new action item inside the actions menu of the ULS is quite simple. All you need to do is to create an action item object and then register it inside the actions menu item registry like that:

mw.uls.ActionsMenuItemsRegistry.register( actionItem );

ULS will take care of everything else. The action item object is expected to have the following properties: name (any name of your preference), icon (the title of the desired icon as defined inside OOUI icons), text (the label of the action item), href (the href of the action item if it's an anchor) and handler (a method to be executed on action item click). If the href property is present, the handler is being ignored, otherwise if href is missing, handler should be defined (otherwise the action item would be useless).

You can also check how we register the "Translate page" action item for Content Translation inside ext.cx.uls.quick.actions.js. Just for your information, the ext.cx.entrypoints.uls.relevantlanguages.js file concerns a totally different entrypoint and it's not really related to the ULS actions menu.

I hope that helps, but if not, I'm always around :)

In T310259#8540270, @Lucas_Werkmeister_WMDE wrote:

The way items are added to the menu from the code perspective seems to be...

@Lucas_Werkmeister_WMDE, Nik provided technical details on how to add new actions to this menu in T310259#8540768, please let us know if those are clear.

Change 883239 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Add link to Item to make adding sitelinks easier

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

The old “edit interlanguage links” link (which still exists in the sidebar AFAICT, at least for now?) links to the specific site link group that the client wiki belongs to (e.g. Wikipedias, Wikisources etc.). In fact, linking to the sitelinks in general doesn’t seem to work very well – the “sitelinks” heading (#sitelinks selector) is only shown on mobile, not on desktop, so a link like https://www.wikidata.org/wiki/Q42#sitelinks doesn’t scroll to anything in particular (compared to e.g. https://www.wikidata.org/wiki/Q42#sitelinks-wikisource. Should we also make the new link point to the right group? (The problem is that I don’t think this information is available in JS yet, so we’d probably have to add it somewhere.)

Change 883239 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add link to Item to make adding sitelinks easier

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

In T310259#8561489, @Lucas_Werkmeister_WMDE wrote:

The old “edit interlanguage links” link (which still exists in the sidebar AFAICT, at least for now?) links to the specific site link group that the client wiki belongs to (e.g. Wikipedias, Wikisources etc.). In fact, linking to the sitelinks in general doesn’t seem to work very well – the “sitelinks” heading (#sitelinks selector) is only shown on mobile, not on desktop, so a link like https://www.wikidata.org/wiki/Q42#sitelinks doesn’t scroll to anything in particular (compared to e.g. https://www.wikidata.org/wiki/Q42#sitelinks-wikisource. Should we also make the new link point to the right group? (The problem is that I don’t think this information is available in JS yet, so we’d probably have to add it somewhere.)

Ugh, I should have double-checked. Somehow, I had assumed that this was only visually hidden, not basically completely removed, because this way, it is also an accessibility issue. Right now, the various sitelink <h3> subheadings are below the "Identifiers" <h2> heading :/. So we might want to reconsider that at some point.

That being said, we should probably still make the effort you suggested and link to the specific subsection. Q42 illustrates that the individual sections can be so long that it might take some scrolling to find the right place. That can be particularly confusing when an Editor comes from Wikipedia and doesn't know Wikidata well.

Change 884886 had a related patch set uploaded (by Nik Gkountas; author: Nik Gkountas):

[mediawiki/extensions/Wikibase@master] Fix name of the "link to Item" entry in the ULS actions menu registry

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

Change 884886 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Fix name of the "link to Item" entry in the ULS actions menu registry

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

Change 885001 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Link to the Site subgroup in the language selector

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

Change 885001 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Link to the Site subgroup in the language selector

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

In T310259#8571831, @gerritbot wrote:

Change 885001 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Link to the Site subgroup in the language selector

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

Is this worth backporting to wmf.21?

In T310259#8577914, @Lucas_Werkmeister_WMDE wrote:

In T310259#8571831, @gerritbot wrote:

Change 885001 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Link to the Site subgroup in the language selector

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

Is this worth backporting to wmf.21?

Not sure, probably for @Arian_Bozorg to decide: Is it good enough for this to appear on wikis next week, or should we put in a bit of extra effort to have it on production already tomorrow?

Well, the link will appear on wikis this week either way (because the first change was merged before the branch cut), but without the backport it will have the “broken” anchor (#sitelinks instead of e.g. #sitelinks-wikipedia).

Currently it shows "Edit language links" link also if article is connected to an item and if there are no sitelinks in other languages yet. Probably instead there should be a link to open Wikibase Client's link with page widget, the one that can be accessed via sidebar, also when item yet isn't connected to Wikidata. Is this covered in some other task?

Is it possible to know which are the messages in this menu in Translatewiki? Thanks

In T310259#8585111, @Pikne wrote:

Currently it shows "Edit language links" link also if article is connected to an item and if there are no sitelinks in other languages yet. Probably instead there should be a link to open Wikibase Client's link with page widget, the one that can be accessed via sidebar, also when item yet isn't connected to Wikidata. Is this covered in some other task?

If I recall correctly, the options to edit links in the previous version of Vector could be used for different cases including wen the item exist with links to other language, lacks links to other languages or does not exist yet on Wikidata. Ideally that should be the case for this action too. For example, looking at unconnected pages, a page like Anniversary Peak which is only available in English for now, is showing the language selector with an empty state to encourage making it available in more. There, the options to translate is present but the option to edit the links in Wikidata is not. If a user had created the page in German and wants to connect it, there is not a clear path to do so.

Adding to Pau's comment above, I checked that the module that registers the “Edit language links” action button is the wikibase.client.vector-2022 module. I checked the loaded modules for the above page (using mw.inspect() inside the Developer’s console) and the module doesn’t seem loaded. This is why the button is not visible. I checked the conditions used to add the module, in the codebase and I believe it's the following condition that prevents the module from being added:

$outputPage->getProperty( 'wikibase_item' ) !== null

The wikibase_item property for this page seems to be undefined. We can easily verify that by using the following API URL: https://en.wikipedia.org/w/api.php?action=query&prop=pageprops&titles=Anniversary_Peak&format=json and check that there is no "wikibase_item" key returned.

So, I think we should also add the wikibase.client.vector-2022 module for pages where wikibase_item property is null.

In T310259#8609888, @Pginer-WMF wrote:

... the "edit language links" option, unlike other options such as "Translate" is not displayed for pages not available in other languages

I still wonder, shouldn't the links and functionality be the same as in old Vector, i.e. display "Add (interlangauge) links" link instead of "Edit interlanguage links", both when not connected to Wikidata and also when connected to Wikidata but without sitelinks in other languages (example)? This link opens the "Link with page" dialog (for logged-in users) instead of directing the user to Wikidata.

In T310259#8609888, @Pginer-WMF wrote:

As mentioned in previous comments (T310259#8588960 and T310259#8589199) there is part of the integration that seems to still be missing. As a result, the "edit language links" option, unlike other options such as "Translate" is not displayed for pages not available in other languages (example ):

IMHO this needs to be a separate Phabricator task, it’s completely separate from this task as currently specified.

So, I think we should also add the wikibase.client.vector-2022 module for pages where wikibase_item property is null.

This is not enough on its own – the current purpose of this module is to link to the sitelink section of the connected item, which isn’t possible if there is no connected item. If fhe wikibase_item guard is removed and the rest of the module not modified, it’ll probably just crash. (Or worse, link to Special:EntityPage/null#sitelinks-wikipedia.)

It’s possible that the implementation of the new functionality for unlinked pages will eventually live in this ResourceLoader module as well, but it needs to be implemented first.