Option 3 (collapsible sections) doesn't exclude 1 (in-line ToC) or 2 (pop-up ToC). Minerva on tablet or phone-landscape widths has both 1+3.

Related question at enwiki helpdesk: https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=1085520277#ToC_gone?

This Phab ticket is also mentioned at https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Notifications/New_messages_popup_for_new_users

Note, there is a 2022 Community Wishlist proposal (by a different community member) related to this ticket at https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Mobile_and_apps/Better_warning_display_for_mobile_users

My concern is with the detection logic, and whether this kind of issue is going to re-occur in future. If Safari/iOS 12.2+ is supposedly 99% ES6 compliant, why is it being excluded?

Similar symptoms confirmed on iOS 12, which as of recently was still receiving security updates from Apple.

For example, this code vector.css works client-side when applied, but I get warnings when editing and saving.

@Base: “but blocks under No open proxies policy indeed are generally for both logged in and anonymous users”
@GeneralNotability: “enwiki - we routinely hardblock open proxies, including CDNs being used as proxies”

This should change. If I'm logged-in, why can't I edit from anywhere?

Agree that this would be a nice enhancement. Until we get some special markup for multi-line list items or delimited comment/post blocks, and unless the detection logic for inserting [ reply ] links changes, I think the tilde detection should only apply to the last paragraph or list item. Rationale at T278442#7249030.

I really appreciate how inserting the [ reply ] links detects any paragraph or list-item that contains both a user-page link and a timestamp, even if they're not at the end, and even if they are not adjacent. Using the same logic to suppress inserting a second signature on preview and save is not just good for flexibility in signing, but also good for consistency.

I found this task from [[mw:Talk:Talk pages project/Replying#Page title doesn't show talk page is being edited]]. I would also lean toward “Replying:” or “Replying - ” rather than “Editing”.

Will you include data from WikiEditor and CharInsert, or is this task only scoped to VE/NWE?

Could the extension have a local cached copy of the last file that passed validation, and fall back to that? (Whether it's worth the effort is a separate question.)

Yes, works for me now. Thanks, everyone.

I found the task where the change was implemented: T252083: Treat links to user pages differently than normal wikilinks

By “improve the link-editing interface in VE”, I’m thinking along the lines of what @Esanders said at T56947#6654173:

we added the label editing field to mobile VE. I think bringing that interface over to desktop would make these mistakes much less common

editing the label of the link instead of its target, much like T56947.

I think the solution is to improve the link-editing interface in VE, not write a special case just for pings.

To the original question, “functions as they expect it to” ... my key expectation was that it works much like in the Visual mode, so yes, it does. Pasting formatted text and having the choice to convert the formatting to wikitext was pleasantly unexpected, since I don’t normally use NWE.

Thanks, @Thryduulf! I agree, I don’t need to see the details, the title is sufficient. Also understand why proper handling of suppressed names would high importance. I’m curious about how that all works under the hood, but I’ll be content with not knowing, to avoid another trip to the rhinologist for beans-removal. ;)

I'd regard T277919 as a blocker.

Restricted task? I don’t have permission to see it.

An example of this causing issues for a contributor:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&oldid=1014908856#Concerns_regarding_article_description_edits_not_appearing/not_being_logged_in_the_%22History%22_of_an_article

Question: should the KPI be “percentage of people” or “percentage of edits/posts”? If a person makes a mixture of successful and unsuccessful posts, do they get counted as a success or a failure overall?

If you must prevent people from changing the summary, then show it but make it disabled/uneditable. At least that way users can see what they are going to get rather than being surprised. It's hidden under Advanced, so the only people who look there are who know and care; you won't be confusing the uninitiated.

On Meta, the last section heading on a talk page has [ edit | Add topic ] instead of just [ edit ].

This task and T91683 are mentioned at https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Editing/Allow_editors_to_control_PageImage

This task and T265713 are mentioned at https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Editing/Allow_editors_to_control_PageImage

@DonTrung that's the non-javascript version of the page. I commented somewhere else that I'd like to be able to access that without disabling JS, but the reaction was along the lines of "what the heck for?"

Do the alternate divs exist in other skins, or will scripts that aim to work across multiple skins need to make an existence check? If the latter, can you provide an example code snippet to aid maintainers?

I was going to file a bug report on this, but I see I’m not the first. FWIW, I just now experienced it on iOS 12 Safari; haven’t checked other platforms. Happens in Vector, Timeless and desktop-web Minerva (but not in mobile-web where the text isn’t present and there’s no visual editing or preview mode, which is a separate problem).

Topic titles

General thoughts about pre-fill, snippet, and behaviour with/without customisable summaries

There are three sub-issues here:

1. Stripping interwiki prefix.
2. Unnecessary percent-encoding. Is that what you get for editing with HTML DOM? Can some trick markup be inserted like what is done to round-trip certain wikicode?
3. Unnecessary piping. May be required for VE to WYSIWYG. It’s a disservice to those who prefer clean source, but what could be done?

Note that people do find the pencil icon confusing. A pencil next to a section heading (mobile/Minerva) or in a page toolbar (narrow Timeless) means Edit. A pencil in an editing toolbar means switch mode. Unless it is actually a highlighter/marker, when it means syntax colouring. In a sidebar or infobox it could mean edit linked data.

It astounds me when I look around my workplace and see people running web browsers or word processors or similar applications in full screen on a 1920-px or wider monitor. And yet they do. (Usually with the actual text only 1/3 of the screen and huge gutters on the sides.)

https://www.mediawiki.org/wiki/Topic:Vopo92swmcdqr2fp

Should step 1 be "Create Template:Main Page/minerva.css with ..." ?

This task is publicised in Tech News 2020, issue 24.

I got this on sup and span lang whilst making a visual-editing reply at diff 426998, described in post vnjnk29hmsb98r71.

Agree with AlexisJazz, about need for more explanation. How is client-side JS more maintainable than server-side?

So, ... this depends on the user's current wiki having Flow extension loaded so that it can post to Structured Discussions on mw-wiki?
I think I'm going to need a "Bex and a good lie down".

Is a CSS class on the whole block sufficient, or should we have additional separate classes for the configurable-text and timestamp sub-components? The intent of T27141 is to allow users to remove custom styling, either would do. Are there use cases where people would want to style the components separately?

Is the sig. really a typeof Comment? (As illustrated in the example at T234966#5575981 above.) Wouldn't the associated text (usually but not necessarily preceding the signature) be the Comment?

I experimented with inserting my local time in my sig. At one stage I had nested {{subst:#time … {{subst:#expr … {{subst:#time …}}}}}} (subst one, subst 'em all), which would be banned under this proposal.

A comparison: desktop VE has a Symbol menu and desktop "classic" editor can have CharInsert, but Structured Discussions and mobile VE(?) only have a language-input selector, no symbols.

To remove the ambiguity, you could display both names in a 2-column drop-down. SD post vkpxssh1ty6lue6t

This shouldn't depend on no-JS stats. I'd like to use the other editor but am not willing to disable JS, so I wouldn't be counted in those.

Should this be renamed from "Ability to select different editors" to "Ability to select different editors for mobile web" or similar?

Can this idea be extended to provide multiple end-user-selectable colour themes for a given skin? E.g. light, sepia, dark, black as in the mobile Wikipedia app and various eBook readers. Ideally something that can be toggled anywhere without going to Settings/Preferences.

Anyway, sorry for the digressions. If we move the 2017 NWE out of beta, but leave the 2006 toolbar as a gadget, then instead of a 3-item drop-down, we could have:

Minor observation: on en-wp,turning on-and-off the setting "Temporarily disable the visual editor while it is in beta" (saving settings in between) resets the Editing mode dropdown back to “Remember my last editor”. Previous preference (in my case “Show me both editor tabs”) is not retained.

So are the actual choices something like as follows? (1)

If the decision is "no bug fixes for such old devices", then fair enough. Just wanted to report that the issue exists.

Agree with Sdkb. This and also the ability to edit or at least see the /* section */ part of the edit summary. See T234982: Varying approaches to section names in edit summaries (mobile vs desktop and visual vs wikitext). Mentioning it because it could be part of the same redesign (add checkbox for minor, add textbox for section).

I respect the concerns of those raising this issue, but mobile devices (and the two dominant OSs that run them) are so prevalent that I don't think it says too much about a person to reveal that they are using the mobile site or the app.

I'm not a huge fan of remember last (which is why I choose two tabs on en.wp), but I do see it as a reasonable approach for logged-out users and for those who don't want to dive into tweaking their preference settings.

For those who are having issues with being given the most-recent editor for redlinks, could we adapt the existing SET preference setting? (English settings pictured below.)

Related tasks:

• T230185: Wrong section in edit summary of mobile editor – relates to edit summary not displayed nor editable in mobile wikitext editor. Aside, I see Jdlrobson mention there that Mobile Frontend isn't involved. Query: who looks after the mobile wikitext UI?
• T62134: Include /* section title */ in edit summary for mobile section edits – where the mobile wikitext section summary was initially added.
  • “When the section title got changed in an edit, desktop uses the original section title while MF uses the new one”
  • T67784: Include /* section title */ in edit summary for mobile section edits. “Yup, it is not displayed there because of space constraints”
• T178159: Enforce section name when editing a section. People can break section links. On the other hand there are cases where it's desirable to edit that info. Also, interesting point about auto-complete.
• T22307: Generate automatic summary /* blah */ when I manually add a section heading when editing. To me there seem to be a lot of edge cases that complicate this. Say, what if an added H3 precedes an added H2, which heading wins? There is some discussion there around user expectations, software silently altering edit summary after submit, whether user should consider /* blah */ as part of "their" edit summary, …
• T2738: Ability to watch section levels of pages. On section watching. Question: if section watching ever happens, will it be based on looking for the section name in edit summary, or some other means? E.g. parsing for changes between headings, tagging sections with unique IDs. How to deal with nested sections? If I edit a H4 section, the edit summary just has /* H4 */ not /* H2 | H3 | H4 */

Apologies for splatter-gunning the tags; this is very much a cross-team question and not sure which ones are most appropriate.

This task looks pretty mature, and a lot of decisions are already committed. A few extra thoughts anyway:

I was planning to log a feature request ticket, but found that this task already exists. For what it’s worth here is my user story:

In T178159#5547735, @Pelagic wrote:

At time of writing this, there is no longer any edit page button on mobile. And the section-name part of the edit summary is not just enforced, but is invisible. If I want to add a section, I have to switch to desktop view or leave an incorrect edit summary.

In Minerva without AMC, you could add a button at the end of the page alongside "Discussion". But this might be too prominent. Could we put it beside the button(s) but make it a smaller link rather than a big button? (Similar to the Cancel link on the right of the Publish | Preview | Changes buttons in desktop wikitext editor, but not bold nor red.)

In T178159#3684012, @Frap wrote:

when inserting navboxes at the bottom

In T178159#3684012, @Frap wrote:

When inserting a section one ought to use the Edit page button instead of edit the section, …
Anyone have any feedback?

This may be a subset of T203151: Consider adding a button to let users edit the whole page in MobileFrontend, depending on the scope of that.

If you remove Thank from desktop history page, you're likely to get an outpouring of complaints, of "where did it go?" questions, and of "we weren't consulted" accusations.

Similarly, is it useful to Undo without seeing the diff?

• Maybe if a user is repeatedly deleting the same sourced material and you see another red "-425" character count again…
• Maybe if you're undoing your own boo-boo.
• Also, a bad Undo can be undone (?) but a mistaken Thank can't be revoked.

Pains me to say this, but issue appears to have been logged previously at T93565: The "All" and "Other" tabs on MobileFrontend watchlist show Flow gibberish topic ID links instead of topic titles.

Thanks for clarifying about AMC, @Jdlrobson.

Ideally there would be two dark themes: very black (for OLED) and not-so-black (for LCD). That's been done for the Wikipedia mobile apps. (And as far back as 2012, T44332 mentioned OLED as a motivator for dark themes.) Maybe "has more colour themes" is a selling point for the app, though.