Also, is my understanding correct that no other language has any changes in the generated Mediawiki files, apart from Kaj ? That would also be a little suspicious.

In T392433#11331580, @Reedy wrote:

Without any extra changes, the patch on T396100 doesn't seem to fix this...

Thank you @Reedy, @Nikerabbit, @matmarex

In T378214#10891284, @matmarex wrote:

I could approve it, but it's not clear to me if we want to ship the currently proposed version (with some time units missing), or wait for CLDR 48.

@Nikerabbit @Reedy The singular/plural rules have been added to CLDR for both, gom-latn and gom-deva, and will be available in CLDR v48 to be released on 22 Oct 2025. So could we please merge the patch, considering that the missing singular units will be available in Mediawiki once we upgrade to v48?

Status update from upstream: The languages id and zh-hans are defined to not have differences between singular and plurals. The singular/plural rules have been added for gom and will be available in CLDR v48 to be released on 22 Oct 2025.

@Pppery I was able to delete the two corrupt Flow boards. With this, we finally complete the archiving and clearing of Flow boards on gomwiki. It certainly feels like we have slayed the many-headed Hydra.

I have created a CLDR ticket: https://unicode-org.atlassian.net/browse/CLDR-18641

Errors while trying to delete:

@Pppery, I have deleted the 68 empty boards, as well as the empty talk pages with links to them, except for the two pages that were affected by the abuse filter, which are giving me an error when I try to delete them:

• https://gom.wikipedia.org/wiki/वापरपी चर्चा:Thibaut120094/Archive_1
• https://gom.wikipedia.org/wiki/वापरपी चर्चा:Matěj Suchánek/Archive 1

@Pppery I had handled 92 non-empty but non-significant pages, which should leave us with 165 - 92 = 73 non-empty pages. And 141 -68 = 73 as well - so everything tallies up. Thanks a lot for the explanation.

@Pppery There seems to be some inconsistency in the number of flow boards on the wiki:

I think we can merge the patch, considering that the singular forms should appear once T392433 is fixed.

Thanks @zoe and @Pppery for your work.

@Reedy, regarding your comment at the patch at line #41

@matmarex, please could you help sort out the situation for gom-latn? Following are the steps that would need to be done:

In T389113#10647212, @DLynch wrote:

Main limitation would be that it currently just tries three times and then gives up, so if there's already an Archive 3 page out there we'd be skipping that page-move. We could either increment the number of tries -- 3 was entirely arbitrary -- or manually handle whatever tiny number of moves that represents.

I noticed that the patch has been merged a few days ago. I may be mistaken, but it appears to me that the translations for kok_Latn (in Wikimedia terminology, gom-latn) have not been added.

@matmarex , we do need your help to make these changes.

I agree with you @Pppery. There are some user talk pages which merely have a welcome template, and some article talk pages with a talk page header template. For example:

In T382810#10424834, @Pppery wrote:

I wrote a script at one point to delete totally blank Flow talk pages and ran it on MediaWiki.org.

Since these pages with curid 8343 and 8344 are exact duplicates of the pages with curid 1719 and 6277, and got unintentionally created, I intend to delete them in the end. Please advise whether and when I should go ahead with the deletion.

This ticket is now seven years old so it's unlikely anybody is going to investigate further. Please go ahead.

Thanks @matmarex for the context and explanation. The Demo Wikis look fine.

Here is the translations php file for gom-latn:

Thanks for the quick solution, @matmarex. I can't believe there could be such a relatively simple fix. I will provide you the php translations file for gom-latn in a day or two, focusing on the time strings, because these are what we need to solve the current bug.

Thanks, it is back to normal now.

In T335758#8821236, @Pppery wrote:

For the record, I changed this because the fallback flow was previously inconsistent with itself (gom -> gom-deva -> en, but gom-deva -> hi -> en), which confused the Babel extension. The fallback from gom-deva to Hindi appears to have been present since the language was added in 2015. As long as the fallback flow is consistent (which it appears these changes would create), I have no objection.

I just noticed that this issue has been fixed. Thank you, and feel free to close this task as resolved.

What currently blocks communities from coordinating their development and merging their tools, to share one tool together?
I'm not convinced this requires "an inbuilt feature in MediaWiki" at all, especially as that could mean there will be 6 attempts in parallel instead of currently 5. :-/

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).