I have made some trials in the meanwhile. It seems that suggested languages list appearing inside language selector dialogue window and the compact list of languages are two different things. And with user page Babel it is only possible to affect the later and not the first. Compact list of languages that exists in the old Vector skin is missing in Vector (2022) skin.
I suggest that Language Selector documentation (https://www.mediawiki.org/wiki/Universal_Language_Selector/Compact_Language_Links) should be updated. I could not find any information on suggested languages list. It looks that the information in the documentation is seriously outdated.

Yes, just discovered it myself. Thanks.

@Iniquity Thank you for merging the tasks. I saw "Unusable ProveIt window" task, but I thought it's about some other bug.

Works now in etwiki. Thanks!

I removed tag in etwiki for now.

The patch has introduced unwanted behavior. If 'proveit-summary' is empty string and 'proveit-tag' is not empty string, then tag is not applied when user saves changes without previewing them. Which is OK. However, if he does preview changes, the tag is applied, and this happens irrespective of whether ProveIt window was opened at all.

Tested it, works like a charm. Thank you! @Sophivorus

@Sophivorus: I tested it and everything works. Great job on getting this fixed!

I think this solution works only if 'proveit-summary' is not empty string. Also, does not work if user manually changes summary added by ProveIt.

@Halfak I see you assigned the task to me. Is this about new campaign? What I'm supposed to do?

@Sophivorus
Sure, I will create a task. Wasn't sure if this is a bug or feature...

@Sophivorus
I played around some with tagging and noticed that the tag is only applied if you press 'Save changes' button straight after editing article with ProveIt. If you press 'Show preview' or 'Show changes' first, the tag is not applied. Apparently, when you set <input> tag in HTML with method addTag, server does not include it in the response sent back to client, thus it is lost.

@Sophivorus Yes, I just checked, and now it shows that edits have ProveIt tag. Just took some time to take effect. Thank you!

Added it to the list of gadgets of Estonian Wikipedia. Initialization code is here: https://et.wikipedia.org/wiki/MediaWiki:Gadget-ProveIt.js

@Urbanecm
Created the translation in translatewiki.net. Now there are Translatewiki translations both for "protect-level-autopatrol" and "restriction-level-autopatrol" system messages. Since etwiki uses custom name for Autopatrollers as Pikne noted, Translatewiki translations can be made to be in correspondence with their literal meanings and I will add custom translations in etwiki.

Created translation at translatewiki.net (https://translatewiki.net/wiki/MediaWiki:Protect-level-autopatrol/et).

@Urbanecm
Would it be possible to create additional protection level based on the group? (I know it is technically possible, I'm asking the question w/ regard to the policy and server administration practices.)

Yep, creating the project page is in plan.

@Urbanecm
Great, thank you!

@Urbanecm OK, just need to wait a day or two.

I opened new discussion in the community. It seems that there is consensus for creating Autopatrollers group in etwiki. Going to wait for a few more days to collect opinions.

@Arseny1992 I see. Would it be better if we requested some standard user group like Autopatrollers?

@MarcoAurelio Thanks for the comment!

@MarcoAurelio The usefulness lies in being able to list certain gadgets under the Preferences > Gadgets where they can be easily installed and yet not have them easily available to all users.
Some gadgets can be abused. For example a gadget that changes hundreds of articles with a couple of clicks. You wouldn't want to have that kind of thing available to some new user, who hasn't yet developed understanding of how some particular aspect (e.g. categories) of Wikipedia works. Such users usually have no clue what a user script is or how to install one. Even most of the experienced users don't know much about user scripts. If we don't make the gadget easily accessible to users, they would not use it. At the same time it is desirable to make it easily accessible to other, experienced users.

Here is the summary.
I proposed to create Autopatrollers user group in etwiki (along the lines of Bulgarian wiki), and stated that the purpose is to allow administrators to flexibly administer some gadget access rights. Described how admins can add/remove users to/from the group.
User Vihelik said we don't need Autopatrollers group since there are too few users in etwiki. User Andres said we don't need Autopatrollers, and that my question was really about Toolusers group, which he does not oppose. User Toon commented on the word Autopatrullijad (Autopatrollers). User Melilac agreed that there should be a way of giving tool rights to trusted users and not give every user rights to tools that can massively change articles (support). I don't understand what was user Pietade's point, but he didn't oppose or support the proposal.
So the tally is: Andres (bureaucrat) and Melilac (administrator) support the proposal; Vihelik (administrator), Toon (user) and Pietade (user) neither oppose or support.

In Bulgarian wiki they use exactly the same tool as we in Estonian wiki (that allows to change categories en masse). They decided to limit the tool use with autopatrol user right. We don't have Autopatrollers user group (and don't need it).
But anyways, it makes no difference from the security standpoint, whether it is standard "autopatrol" or "tooluse" right, as in both cases Javascript code can be copied to user's common.js.

I am aware that anyone can install any Javascript code and do anything that his rights in wiki allow.
We discussed it year ago (here: https://et.wikipedia.org/wiki/Vikipeedia:%C3%9Cldine_arutelu/Arhiiv_33#Kategooriate_teisaldamise_t.C3.B6.C3.B6riist) and I raised the exact same point.
It is security through obscurity but it is better than nothing. If some user starts to abuse any script, we would block him and deal with him through the usual ways of blocking vandals.
Most users are not technically advanced enough to modify scripts or to understand how to bypass restrictions.

https://www.mediawiki.org/wiki/Manual:User_rights#Adding_new_rights

Urbanecm, we would like both new right and new group. The right can be used in
MediaWiki:Gadgets-definition (for example this example <pre>CategoryMaster[ResourceLoader|rights=delete]|CategoryMaster.js|CategoryMaster.css</pre> uses the right delete for access check). And to use the right, we need a new group with that right. The group that can be assigned to users by admins.

Hi!
We didn't discuss giving bot rights to the group in etwiki, so I think it's better not to give this right to the group. The user group should just have the "tooluse" right.

I have tested saving data with using Javascript localStorage.setItem directly (without using jquery.jStorage wrapper). In this case data is consistently recorded and survives logging out and in.

Just did some tests and now the data is not lost on https://test2.wikipedia.org/ server after logging out and back in. In the live https://en.wikipedia.org/ server the data is lost.

Userscripts can be saved locally during their development. This way frequent changes made to the script will not pollute history. It's a recommended way of developing userscripts per https://en.wikipedia.org/wiki/Wikipedia:User_scripts/Guide. (Userscript in Wikipedia terms can be any script written in Javascript that is inserted into the page).
Loading a local script is no different than having it load from Wikipedia server, just source is different.