This issue has gotten resolved by itself :)

If I were to fix it in the local CSS, I would reduce vector-sticky-header-context-bar-primary font-size: 1.5em; to 1.3em (slightly bigger than h3) and increase vector-sticky-header height: 3.125rem; to 3.725rem.

If you want checkwiki errors to be detected, you will also need to create and configure checkwiki configuration page.

The menu variations for the ULS should have similar structure, width, placement of submenus.
Fewer nested submodals. Variants of ULS could be tabs in a single interface.

To increase the clarity, I have split this task into two subtasks:
T330042 for T319264#8597234
T330043 for T319264#8597257

In T319264#8391028, @The_Discoverer wrote:

In addition, the step described as If there are only a few language links displayed, then one has to click on "281 more" is something I could not reproduce.

When I tried it today, I could also not reproduce it consistently, but it did happen to me once earlier today on the Konkani Wikipedia. I did not manage to take a screenshot, but I will do so the next time this happens. This seems to be some separate issue, and I have a hunch it might have to do with some conflict caused by some gadgets.

@Pginer-WMF , one more thing: In pages not available in other languages, and pages where it is not possible to connect across languages, the access to language settings is visually similar (cog icon with the text 'Open language settings'). On the other hand in pages available in different languages, there is only the cog icon. I strongly suggest that from the UX point of view, we should have visually the same access for all three cases. This can be accomplished by adding the blue cog icon with the text on pages that are avilable in different languages.

@Pginer-WMF , thanks for your work. I think this task is nearly resolved after the changes. There is only one namespace remaining now which has the language settings at another location: Special pages. In special pages, the language settings are still to be accessed from the left sidebar.

@Aklapper , you are right, it is IndicTechComShortUrl.js that inserting the share icon, and the relevant code is:

Related request T326981 to implement 'display languages' and 'input settings' buttons in the Languages drop-down in Vector 2022, similar to how it is in ULS in the personal toolbar.

@Pginer-WMF, I think that the language settings should be available on every page. This includes all the cases mentioned above, and special pages too. This is important for users of multilingual and multi-script wikis. Access to the language setting were available on every page in the old vector skin through the cog icon in the sidebar. There was an old task in Phabricator that cited statistics showing that the vast majority of UI language changes by users were effected using the ULS and not from the preferences. Do we have good reasons to think that access to language settings is not required from every page on the wiki?

I had forgotten about the discussion I had with @Pginer-WMF (quite a while ago now) about maintaining a consistent entry point for the language settings.
@ovasileva given the criteria from the language team that the language switcher/tools should be available in a consistent place maybe this task should be more about reducing the size/appearance of the language switcher on pages that don't allow for translation?

This is a step in the right direction. Instead of the gear icon, could we show the two sub-options of the language settings (UI language and Input language) visible directly? I have seen a few discussions in the past where users have said that use of the gear icon is not intuitive and people only realise what it does when someone else points it out to them. Even though the gear icon is what we have been using for a long time, now that we are redesigning Vector, it's the right time to think about what we can improve and not to stick with what we have had in the past. At the bare minimum, the gear icon should be accompanied with the words 'Language settings'.

In addition, on special pages in Vector22, the user has to access the language settings using the old gear icon in the sidebar. Thus, the location of the point of access varies a lot.

In addition, the step described as If there are only a few language links displayed, then one has to click on "281 more" is something I could not reproduce.

With the new Vector 2022, the language selector has changed location to a more prominent place at the top of the page. At a more prominent location, exposing many different tools has the risk of fragmenting user attention. Thus, the idea was to integrate language-related options from a unified language access point. With language switching as the main functionality and a "more" option to access other language-related options.

In the comparison with the previous location, this point of access does no longer require scrolling or scanning a sidebar full of links. So that also represents steps that are saved with the change.

@Xqt, it appears that welcome.py is not working with Flow user talk pages. I set up a bot (tool discobot on ToolForge, User:DiskoBot). When User:DiskoBot made its first edit on the Konkani Wikipedia, welcome.py seems to have done nothing.

Thank you. Reply Tool is up and running for everyone on gomwiktionary.

@The_Discoverer: are you able to share a link to the page where you all discussed enabling the Reply Tool for everyone gom.wikitionary by default? ...I didn't see anything mentioned in these two discussions.[i][ii]

@matmarex: Thank you! :)
Is it possible for DiscussionTools to be enabled for all users by default (rather for individual users to have to enable it manually)? In our community discussion, we wanted it enabled for every one.

@Xqt , I will set a bot up and report here.

Thanks @Xqt. Will welcome.py work with Flow user pages? All user talk pages in the Konkani Wiktionary are in Flow.

In T271083#6718917, @Peachey88 wrote:

Extension:NewUserMessage was the system that provided the automatic welcomes instead of a bot, But was disabled due to not working with Flow, Looks like its been forgotten about since 2018 T131957: NewUserMessage should handle Flow properly; affects gomwiki/Konkani Wikipedia and kabwiki

In T271083#6718498, @Xqt wrote:

welcom.py is not localized for gomwiki. @The_Discoverer: Could you please have a look at welcome.py netext dict and probably the others too. What is the right message to be written on new users talk page?

No problem, thanks for your work.

The statistics are still not available.

Thanks :)

In T258033#6479651, @gerritbot wrote:

Change 628791 had a related patch set uploaded (by Joal; owner: Joal):
[analytics/refinery@master] Add 3 new projects to the sqoop list

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

Thanks @Nintendofan885

Thank you everyone for the patch.

Yes, it's working now and I have imported some templates. Thanks for all the support you are providing us, @jhsoby :)

Thanks for the quick action! :)

For reference, this was the previous instance of the update: T191339

In T249506#6032190, @MF-Warburg wrote:

The community also requested "Give Flow board creation rights automatically to admins on the Konkani Wiktionary (Add flow-create-board for gomwikt sysop)" for the settings. I don't know to whom this right is usually assigned (on mw.org to all users, it seems), so I don't know if that is a restriction and how feasible that is given the scarcity of sysops on new wikis ( @Aklapper cf. our recent discussion).

Thanks once again, @MarcoAurelio . I didn't know that we had started editing the release notes file in the same patch as the code.

Thanks, @MarcoAurelio . Who can merge this?

No, only template and template_talk. May I add a patch?

At present we don't have an admin on the Konkani Wikipedia who would be able to do this, so I would appreciate if a steward could implement it for us.

@MarcoAurelio, per T40863, we would like to have the ShortURL link with the grey share icon and tooltip instead of the link being displayed below the page title (i.e. we would like to have it the way it is in the Hindi Wikipedia). Since it seems that T40863 will take some time to materialise, please could you implement this in the Konkani Wikipedia?

Thanks @MarcoAurelio, that was fast. In fact, it's one of the fastest I've seen a task resolved on Phabricator. :)

In T134344#3733232, @Amire80 wrote:

(although I also doubt that for this case it's useful to have the interface in Latin while the content is in Devanagari, but it's possible that I misunderstand something)

Thank you :)

There was a bugfix to 2.18 and the latest version available is now 2.18.1

Thanks to all of you for your help. :)

Progress report
3 out of the 4 patches have been merged.
The only remaining patch is https://gerrit.wikimedia.org/r/335030
Does anyone have any information regarding this file?

Thanks everyone!

Thanks @KartikMistry

@TTO, I found 4 files that still contained the old names and created patches for them that need to be reviewed and merged

Thank you @KartikMistry

@KartikMistry , thanks for merging. Do you know when the change will go live in ULS in Wikipedia?

@Aklapper , please could you assign this to someone from the ULS team to merge the patches? Thanks.

Two pull requests in Github to be reviewed and merged:
https://github.com/wikimedia/jquery.uls/pull/247
https://github.com/wikimedia/jquery.ime/pull/459

Thanks everyone. I will wait for the second patch to go live and then close the task.

What I wanted to highlight with this bug report was that the pages with curid 8343 and 8344 should not exist in the first place. Did these pages get created due to a known issue or a user error?

No it hasn't been discussed on the Wikipedia. @Catrope suggested we do this when I requested him to create a flow page for me. He said that either he or @Mattflaschen-WMF will take it up.