From the mentioned task, we were hoping to announce this feature's availability in Tech News. Lucas suggested this (T338834#9081727) as a rough entry draft, but that was in Aug 2023 so it's very late.
Is this still worth announcing onwiki? Will documentation be available soon or is it already?
Lucas's draft was:

Version 1.0 of Codex, the design system for Wikimedia, has been published. It can be used by gadget or user script developers via the TODO ResourceLoader module (TODO docs link?), and by tool developers via the Toolforge CDNjs mirror (announcement).

(The linked prior 'announcement' was sent to both wikitech-l@ and cloud@ mailing-lists.)

I believe we were still waiting for the sub-task to be resolved, of writing documentation on how to use it. I will move the draft-summary and tag over to that task.

@Danny_Benjafield_WMDE Is this ready to be added to Tech News now, and is the draft still good? Cf. our prior discussion above at T66315#10091158.

Does this change need to be announced in Tech News? I see some back-and-forth in the task above (removing and re-adding the User-notice tag - @Pppery). If it does need to be announced, please could someone propose some wording, of what editors will want/need to learn about this change? Thanks!

I think that's just how they need to work. I.e. Unfortunately, I suspect it's too complex (filled with edge-cases) to change anything significantly, for the default subpage-breadcrumbs feature.
The only design I can imagine (but not support!), that would both eliminate the duplication, and retain the important prominent contextual-clues (of the full page title displayed at top), and also support the copy&paste workflow, would be to split the <h1> header itself into separate parts and link the parts that exist.
But there are so many drawbacks and edge-cases to that idea that I imagine it would add just as many frustrations as it solved.
E.g. Would the headers then become partially Blue? (cf. https://www.mediawiki.org/wiki/User:Quiddity/Blue_link_color ) I.e. A page like https://meta.wikimedia.org/wiki/Tech/News/2024/50 could theoretically have a page-title that looks like "Tech/News/2024/50"
However that would be counter to the Manual of Style on Enwiki (and possibly/probably others?), that states: "Section headings should not themselves contain links; instead, a {{main}} or {{see also}} template should be placed immediately after the heading." -- and I expect changing the page-title headers like that would lead to a lot more newcomers creating links in sub-headings and then getting reverted.

Yup! I would say there's a firm distinction between the pages which are using the default MediaWiki "subpages automatically create breadcrumbs" feature (documented at https://www.mediawiki.org/wiki/Help:Subpages), versus the custom examples at Wiktionary and Wikivoyage.
I.e. The results of this task might affect the former, but wouldn't touch the latter (unless those communities decided to update their templates as a result).

I would push back on that proposal. Technically, it's the full page-name that is showing, and I think it would be very unwanted, to trim that in a majority of cases, as the full-name is often crucial context to read all at once.
E.g. https://meta.wikimedia.org/wiki/Tech/News/2024/50 should not just show "50" as the page-title, and https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Record_charts/Sourcing_guide/Japan should not just show "Japan" as the page-title, as those would be confusing for people who didn't notice/understand the breadcrumbs.

Removing tag, because IIUC this is a subtask about adding metrics, and hence doesn't need a separate announcement. Please undo if I've misunderstood. :)

In T361745#9694315, @CCiufo-WMF wrote:

@JFernandez-WMF the Growth uses cases appear to be single links to return to a previous (or higher order) page ("back links"), while the other use cases are what I would call more traditional "breadcrumb" examples. Are there situations where the Growth use cases would have deeper nesting, or it is always just a single "back link"?

Thank you! For the record (or in case edits are needed before it is frozen on Friday), I've added it to https://meta.wikimedia.org/wiki/Tech/News/2024/49 using the wording:

Starting this week, Wikimedia wikis no longer support connections using old RSA-based HTTPS certificates, specifically rsa-2048. This change is to improve security for all users. Some older, unsupported browser or smartphone devices will be unable to connect; Instead, they will display a connectivity error. See the HTTPS Browser Recommendations page for more-detailed information. All modern operating systems and browsers are always able to reach Wikimedia projects. (1)

Hi, I believe this change probably deserves an entry in Tech News. The last similar change that I'm aware of, was announced using this wording (below).
Please could someone help me by writing a similar entry, for this upcoming change?

You can no longer read Wikimedia wikis if your browser use old TLS versions. This is because it is a security problem for everyone. It can lead to downgrade attacks. Since October 29, 2020, users who use old TLS versions will not be able to connect to Wikimedia projects. A list of recommended browsers is available. All modern operating systems and browsers are always able to reach Wikimedia projects."

Thanks.

I will include it in Tech News as this (unless anyone suggests something better in the next couple of hours):

The CodeEditor, which can be used in JavaScript, CSS, JSON, and Lua pages, now offers live autocompletions. Thanks to SD0001 for this improvement. The feature can be temporarily disabled by clicking Ctrl+, and un-selecting "Live Autocompletion".

Hmm, I wonder if this is due to browser font-settings... I've got my Firefox1.32/Mint configured to use "size 17" and if I lower that to 15 then the problem stops. I cannot determine what the browser default is, and screenshots on the web seem to indicate it's 16, but I still get the jumping-search problem (but only for 1120px to 1124px) at size 16. I.e.

I tested at Commons and couldn't reproduce.

Re: User-notice - I agree this is probably not suitable for Tech News. (I.e. There are hundreds of regular improvements to MediaWiki which are great but are not worth distracting everyone with announcements about).

@Jdlrobson I'd recommend tagging the original task with #user-notice in the future. That makes it easier for me/other TN editors to read any associated comments/concerns/contexts, and thus more easily notice and propose any tweaks to a draft-entry, and to potentially notice things like patch-reverts/merges. Plus it reduces the quantity of threads in our inboxes (for those who use email to triage).

It seems like this should be included in the next (or a near-future) Tech News edition.
Please could someone propose some wording/links for a Tech News entry? Please also confirm whether it should be in the upcoming edition (Frozen on Friday, sent on Monday), or the edition after that. Thanks.

Thanks! This seems resolved, albeit just from a single test. -- I successfully moved mw:User talk:Quiddity (WMF)/sandbox11 to mw:User talk:Quiddity (WMF)/sandbox11-1.

@sbassett It was included in https://meta.wikimedia.org/wiki/Tech/News/2024/43 (or archived plaintext mailing list entry). :-)

In T376749#10283307, @DLynch wrote:

(But I'd assume that manual cleanup happened before we turned them off.)

Closing, as no longer reproducible. The problematic pages were deleted, and were only sometimes showing the error message, so undeleting -to-test might not help. The remaining large gallery pages (example) seem to work fine. Plus things have moved to SUL since, which makes this task even less relevant.

@tstarling Thanks! Is there a documentation page#section that it can link to?

Please could someone suggest wording for this proposed Tech News entry, including what documentation it should link to. Thanks.

That looks good. One more suggestion: Add a sentence explaining the new acronym "CNA" (currently undefined, but used in the header). It appears to be best-defined at https://www.cve.org/PartnerInformation/Partner

@Aklapper True. Maybe the proposed section belongs in a subpage of "mw:Wikimedia Security Team", instead.

@sbassett I'd hesitantly suggest adding a section at the bottom of (2 / https://www.mediawiki.org/wiki/Reporting_security_bugs), above the "Related security content" footer box, with some simple details.
It could perhaps mostly just repeat the Tech News item, with 1 or 2 more links, and 1 or 2 more sentences. E.g. something like...

== CVE Records ==
The Wikimedia Foundation is an official partner of the CVE program since 2024, which is an international effort to catalog publicly disclosed cybersecurity vulnerabilities. This partnership allows the Security Team to instantly publish common vulnerabilities and exposures (CVE) records that are affecting MediaWiki core, extensions, and skins, along with any other code the Foundation is a steward of.

Our CVE records are publicly announced in this gitlab repository ... --- (??? which [someone?] should pay attention to, or use in some way??? cf. my earlier question. --- Or, maybe just add a reminder to subscribe to the mailinglist and link to https://www.mediawiki.org/wiki/Security#Receive_MediaWiki_release_notifications ? I.e. A sentence answering "How is this relevant to me?" for whomever that records-repo is relevant for.)

The Security team has internal documentation on the Supplemental Release Process.

This sounds good for Tech News. However we don't usually link to external websites from Tech News entries, so I'd like your help determining where the entry should link to, and also refining the wording.

My confusion has been resolved, and an entry added to Tech News.

I'm wondering if we can expand that Tech News draft with a bit more detail, particularly for anyone unfamiliar with it all...

Issue resolved. An extra < in the wikitext was causing the problem.

<<translate><!--T:1--> ...

Devs say they might be able to add a clearer error message for this type of thing, so I'll leave this task open for now.