In case helpful, I noticed that my Firefox and Chromium (both latest, on Linux Mint) are displaying different colors from your screenshots above. So I'd guess these are partially OS-defined/overriden colors? (However, I have previously selected a "dark grey" theme for my Mint OS configuration, so I'm likely not seeing the 'defaults')

Tech News draft slightly adjusted/simplified, and added to Description. It will be ready for announcement in the 8th December edition.
We still need to get the correct link for the "100 Wikipedias", and potentially find a place onwiki to document the screenshot and a sentence explaining it. [I'll work on those aspects]

Tech News draft (WIP):

Later this week, some [Wikipedia? all?] editors using the mobile visualeditor who are editing a section in Visual editor will be shown a button that can expand their editing session to the whole page. This A/B test should enable editors to more easily access the rest of the article mid-edit and lower the edit-abandonment rate. [1]

Removing myself as assignee. I believe this task was handed off to folks with more topical expertise, and possibly also resolved in the time since? Let me/us know if CRS help is still needed.

+1 Iniquity. The string in the edit summary should be localizable. Or...
Or, perhaps it should be left out entirely, if localizing it is much harder?
Or if there are concerns about the UX being confusing? (I.e. When *normally* the /* string */ results in a link to a relevant section (from History/Diff/Feed pages) but in these cases it won't.)
Personal context: I usually just delete that "/* top */" placeholder, when I'm editing with the gadget on Enwiki, as the "top" doesn't really provide any useful context beyond the edit summary I manually write; it's just clutter in my opinion/experience.

Source: https://en.wikipedia.org/wiki/Bob_Apodaca#References

I believe the older comments are still accurate. In summary:

• From a community decision perspective, IMO it would be fine to raise the limit for moved subpages from 100→500 at any/all wikis, because only admins can do it, so this change would merely simplify their lives for the current edge-cases. (I.e. No consultation is needed. We'd only want to provide a Tech News (or local) announcement at the same time as the change)
  • It would especially make things easier at Meta-wiki and MediaWiki-wiki, where we often have to move hundreds of translation-chunk-subpages, plus making things easier at content-projects that heavily utilize the subpage feature in the content namespace(s) [like all Wikisources].
  • [@Pppery please chime in if you disagree with any of this, or have more context that needs to be considered]
• From a technical perspective, I think we're just waiting on Performance/Platform team to give a go-ahead to either/both of: (A) Raise the limit at individual wikis when they request it, as here, (B) Raise the limit globally.
  • The latter is (perhaps, I'd guess) dependent on "Does it scale well, if multiple wikis/admins start using this increased limit simultaneously?"
  • @Krinkle Should we re-tag this task with MediaWiki-Platform-Team (or another tag) for you/team to do the technical evaluation/decision? (Cf. your comment above)

I think this feature sounds exciting, per your comments and linked-experiments above, and I worry the current draft-entry, and the documentation it links to, doesn't communicate that clearly to newcomers to this feature. In particular, the documentation doesn't seem to contain any specific examples of how this can be used. We don't usually link to user-sandboxes, especially English-language-only ones, so that's not a great option.
How could we improve the announcement, and the linked documentation, so that the powerful possibilities are more obvious to readers?

Scribunto modules can now be used to generate SVG images. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files.

Is this definitely ready to go, and is there anything else we can add about how the category will automatically-empty itself? I.e. I see the Welsh Wikipedia's category (https://cy.wikipedia.org/wiki/Categori:Pages_using_the_JsonConfig_extension) still has ~7000 entries; however if I look at articles within that category there is no reference to the category on the page (i.e. it's not even listed in the Hidden Categories). I tried a Null Edit, and that removed the example article from the category, so I think I understand this to be a caching issue. Therefore, I think we should add a sentence to the entry explaining this, to avoid confusion.
I suggest we add the sentence

"It is ok if there still pages listed in the category, as that is a caching issue, and they will automatically be cleared out the next time each page is edited."

But if anyone has a clearer/shorter way to describe this, please do suggest something!

There's a comment (at https://meta.wikimedia.org/wiki/Tech#Editing_Watchlists_on_different_Wikimedia_projects) that I believe is related to this task. The editor there (Sabelöga) notes that: On some wikis [I see Group0 & Group1 wikis] in the Special:EditWatchlist page there is no longer a TableOfContents shown for the different sections [regression?], and Temporarily-watchlisted pages are no longer grouped at the top of each section [which Dom mentioned in the last bulletpoint above]. I will reply there, pointing them here.

+1 to including that second paragraph as useful context.
P.s. Note for @STei-WMF : In Tech News, we can replace the plain 'name' of the preference (and buttons), with the actual interface string's name (discussiontools-preference-autotopicsub - found via the QQX trick), so that readers in more languages (beyond those which are manually translated by volunteers for Tech News itself) can get a hint about the context. -- That also benefits Tech News translators, as they won't have to look-up the exact wording that is used in their language, in order to write it accurately in Tech News. -- I.e. Final draft suggestion (also with an added link for the DiscussionTools feature help-page):

For users with "{{int:discussiontools-preference-autotopicsub}}" [[Special:Preferences#mw-prefsection-editing|enabled in their preferences]], starting a new topic or adding a reply to an existing topic with the source editor will now subscribe them to replies to that topic. Previously, this would only happen if the DiscussionTools "{{int:Skin-action-addsection}}" or "{{int:Discussiontools-replybutton}}" widgets were used. When DiscussionTools was originally launched existing accounts were not opted-in to automatic topic subscriptions, so this change should primarily affect newer accounts and users who have deliberately changed their preferences since that time.

Timing: Not this edition, but the following week's (#45).

Thanks for testing PrimeHunter. "cite web" in the wiktext editor did work for me initially, just before I filed this task (i.e. I entered the URL and clicked the Autofill button, and after a few seconds it auto-filled the Title and Website name parameters), but I cannot reproduce it now. I'm not sure if that's related (IIRC they use different backends?). But good to note.

Declining ancient Flow task

Declining ancient Flow task

Now added (with tweaks) to https://meta.wikimedia.org/wiki/Tech/News/2025/42 - reassigning back to product owner.

This user-notice was handled as part of https://phabricator.wikimedia.org/T399669#11234558

Thank you, stjn, that helps. We'll plan to potentially put this in the following week's edition (or once we've confirmed the categories have auto-emptied), using your draft, with links like below, unless anyone suggests further wording/timing changes:

• Administrators can delete the tracking category which was previously added by the JsonConfig extension, as it is no longer used. See the categories linked from Q130635582 .

@Nemoralis (or @cscott or anyone!) Please could you suggest draft wording, or help further explain what exactly admins are being instructed to do? I.e. I checked a few examples linked from (Q130635582) and it seems the category is heavily used in some places (e.g. Welsh Wikipedia's category has ~144,000 entries) so it seems admins (might?) need to do something more than just delete the local category page? -- Or maybe those entries will automatically vanish once the category stops existing? (If so, maybe we can mention that in the entry, to prevent downstream confusion!). Thanks.

That email address is not currently subscribed to that mailing list. Either your latest unsubscription attempt worked, or someone else manually unsubscribed you, (or, speculating, you might be subscribed with a different address that is auto-forwarding? Although I imagine that might be obvious from the headers, so probably not that.)

I advocate for this being an important thing to fix. Today I was very confused about why I couldn't find many results for "call", and I had started to draft a request for people to add all the other regional calls until I stumbled upon an example of a "Call" that already had an event, whereupon I realized this was a bug, and there are actually many "Call" events already listed.

This was announced in https://meta.wikimedia.org/wiki/Tech/News/2025/34

For Tech News (for next week's edition) please could someone propose suggested wording for an entry? It sounds like there was a bug which has caused some errors in the wikitext of a small number of pages, and cleanup is needed - If that is accurate, it would be very helpful if we could link to a listing/search of the errors so that editors can easily find and fix those instances. Thanks.

For Tech News timing, I believe the ongoing discussion/patches here are an indicator that we should postpone announcing it. I.e. until the feature is stable, and has documentation that we can link it to. If nobody replies by tomorrow, then I will move the draft-entry into the following week's edition, so that translators don't waste some of their time if it needs to be rewritten. [EDIT: Now moved.] Thanks!
For content, the current draft is:

• A new parser function has been added: {{#contentmodel}}. It returns either the localized name or the canonical name of the content model of a specific page. The function is primarily intended for use in system messages, such as Mediawiki: editing interface, and in switches. [5]

which I hope we can make clearer by more clearly describing (or giving an example of?) the use-cases, plus a better #section-link for the first link once it's been documented there. Thanks!

Hi @Zabe, It looks like you helped process the last few wiki creations, hence I'm asking you: Is there anything the folks who are requesting this wiki need to do, before it can move along? They've removed the list of extensions (from the Task-Description) that earlier comments were asking about, and have asked me if there's anything else they need to/should do. Much thanks!

Thanks for the draft! Based on our quick chat, and your update to the docs, I'm tweaking that to:

• References lists that are made using <references/> will now automatically display with columns in Vector 2022 when readers are using its 'standard' font-size and page-width settings.[ 1 ]

Now onwiki at https://meta.wikimedia.org/wiki/Tech/News/2025/38

In T328254#11155654, @SomeRandomDeveloper wrote:

In T328254#11153626, @Quiddity wrote:

For Tech News: How would you suggest describing this in an entry?

The new parser function {{#contentmodel}} has been added. It returns either the localized or the canonical name of the content model of a specific page. The function is primarily intended for use in system messages, such as Mediawiki:editinginterface, and in switches.

In T317599#11153281, @A_smart_kitten wrote:

Moving to the 'Announce in next Tech/News' column now that the reindexing in T402220 seems to be complete, and this new functionality is hopefully now available on all Wikimedia wikis :)

For Tech News: How would you suggest describing this in an entry? Is there any documentation to link to? Will this be available immediately on Monday, or during the week with the deployment train? Thanks. [Note: I may postpone until the following week's edition, especially if it's a train-deployed feature, so that editors can start using it immediately upon learning about it. Plus potentially to give time for good docs to be written!]

For Tech News, please could someone both confirm if it is important to include this in Tech News, and if so, suggest draft wording for an entry? I'm not sure how much this change will affect existing uses, or if editors will need to do/fix anything based on this change. Thanks.

Message translated and sent: https://pt.wikibooks.org/wiki/Topic:Yy5wvcw7yqwwtjnx (If needed: English original)

Thanks for Draft for Tech News! A few notes/questions @ppelberg :

1. IIUC, it's getting released with the train next week, so I will rewrite the lead from "Next week" to "Later this week". Plus I'll include links to both the project-page and the Beta prefs:

Later this week, people who are logged in and have the "Discussion tools" Beta Feature enabled will gain the ability to "Thank" individual comments directly from talk pages, rather than needing to navigate to page history. [Learn more](phab:T400849)

2. For the "Learn more" link, I recommend creating a new section at the bottom of the project page, with the 2 screenshots from the task-Description above, and a few brief sentences. (for long-term documentation, and for translatability). Then we could link to that, instead of this task.
3. I notice that some wikis don't have the Discussion Tools feature within their Beta Features at all, e.g. Meta-wiki's and MediaWiki-wiki's and Enwikisource's. -- I suggest we contextualize this distinction in the TechNews entry by adding (bold for the added bits) "... Beta Feature [available at their wiki and] enabled will gain...". -- Question: Is there a listing that we can link to, of which wikis currently have the Beta Feature (and perhaps the timeline for further rollouts)? [Hmm, I've found the listing at https://www.mediawiki.org/wiki/Talk_pages_project/Deployment_Status#Deployment_Status but that seems to imply that this Beta Feature will only become available at 14 wikis? If that is true, we should rewrite the TechNews entry a bit more to make that very clear...] - Please clarify. Thanks!

Thanks for the suggestion and draft! A few suggestions/questions:
(1) Content: Is this rewrite accurate and good, or tweakable to something good?

• Administrators can now access the Special:BlockedExternalDomains page from the Special:CommunityConfiguration list page. This makes it easier to find.

Are there any other technical aspects/changes that need to be mentioned? -- I.e. I'm uncertain whether we need to mention anything about "Functionally-wise, blocked external domains should work as before" -- from a glance comparison (of Beta Cluster versus MediaWikiwiki), it seems like the features are identical from a user-perspective.

I'd recommend reading the related discussion in T195229: Feature request: "clearyourcache" message should only show information for the specific browser being used (instead of all browsers) before working on code-changes for this task. We need to agree on the final goal/result, before implementing changes.
E.g. From the comments there, I and SD0001 believe it might be clearer to just mention the single key-combination that works for all major browsers, as currently written in the first 2 sentences of Enwiki's custom version at https://en.wikipedia.org/wiki/MediaWiki:Clearyourcache - I.e. (with appropriate formatting to-be-added)

Note: After saving, you have to bypass your browser's cache to see the changes. Google Chrome, Firefox, Microsoft Edge and Safari: Hold down the ⇧ Shift key and click the Reload toolbar button.

But first, someone(?) needs to make the final decision about exactly what wording to use, so that we don't waste the time of translators with multiple changes.

Thanks! Re: page-names, I think it would be best to use the generic /Flow, for now. (Context: I already asked, in my last MassMessage to those 2 pages, if they wanted something different, but nobody replied. It's a minor detail, either way.)

I agree it would be easier for everyone if we (WMF) could do this update, for them.
The only part I cannot do myself is "Move" those 2 current pages to be .../Flow subpages.

[personal perspective] If I understand correctly, it looks like this discussion proposes constraining the width of tables, both when the Tools/Appearance menus are expanded, but also when they are all collapsed.
I suggest that it would be ideal to continue the past practice of NOT constraining the table-width, if there are no expanded menus to overlap with.