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

Out of curiosity, how does the system determine "matching page" in other projects? Same name, same wikidata, existence of in-page links or templates? Are redirects considered?