Notes in case useful: I was surprised by the large visible highlight on that empty line in the <textarea> (2nd screenshot).
If I saw that, I would assume there was a [space] character on that line, and I would try to delete it.

Yes, adding the address to the body would be perfect. Thank you so much for looking into this, both of you!

@Ryasmeen We're currently configuring it to only recognize duplicates within the same paragraph. We may change that in the future to be within the same [section/sub-section], hence the wording currently used in the user-visible card itself.

Please could someone reply to my questions/notes above (in T170874#11592944) so that we (Sandister this week) can write a good Tech News entry? (Or help us decide whether to postpone the announcement until those questions are addressed?). Thanks.

@Ammarpad Hiyo. I'm wondering if you might be able to take a look at this? I'm [not a developer but] hopeful it might be an easy bug to resolve, as the other parts of the system are working as expected, just not this single form-field. [I'm pinging you, as you're listed as the extension-maintainer]. Much thanks if you can!

Re: Tech News - Thanks for the draft! I'll postpone including this until next week's edition so that editors can immediately see the content when they read about, as I see it is not yet available on production wikis (e.g. Enwiki's version of that example page) (but is on Beta Cluster's version).

@SomeRandomDeveloper I've tweaked the Tech News entry to use this wording, which I believe is both clearer and easier to translate. Please edit that onwiki (within the next 24 hours) if further adjustments are needed. Thanks!

• When editors preview a wikitext edit, the reminder box that they are only seeing a preview (which is shown at the top), now has a grey/neutral background instead of a yellow/warning background. This makes it easier to distinguish preview notes from actual warnings (for example, edit conflicts or problematic redirect targets), which will now be shown in separate warning or error boxes. [https://phabricator.wikimedia.org/T414742]

As a user, I was confused by the location of the "next" button. I suggest/request moving those buttons so that they are directly next to the page-quantity dropdown menu, near where the former equivalent-links used to be.
I.e. The wide-separation in this screenshot confused me; especially so because I'm a longterm user who expects to find "next" in the usual place, but I believe this would apply to any new user, too:

This was done as the 2024 reader survey https://meta.wikimedia.org/wiki/Tech/News/Reader_survey_2024

In T362828#11530132, @Michael wrote:

[...] but https://test.wikipedia.org/wiki/Special:CommunityConfiguration/GrowthSuggestedEdits#link_recommendation already works, but it is not discoverable if you're not a web developer.

I cannot reproduce anymore. I assume this was accidentally resolved by subsequent code-changes. I'll mark this as no longer valid.

In T411722#11512828, @Jdforrester-WMF wrote:

• Talk to @Quiddity to see if there's an existing worklist of stuff to stand up a new community wiki. Esp. "pages that a wiki needs to have".

This is simple/intuitive enough that it doesn't seem to need separate documentation. I've updated the Tech News draft accordingly, to put the main details within.

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