User Details
- User Since
- Sep 21 2019, 2:03 PM (69 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Pelagic [ Global Accounts ]
Sat, Dec 26
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.
Thu, Dec 24
On Meta, the last section heading on a talk page has [ edit | Add topic ] instead of just [ edit ].
Dec 18 2020
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?"
Nov 28 2020
Oct 31 2020
Oct 21 2020
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?
Aug 5 2020
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).
Jul 25 2020
Topic titles
General thoughts about pre-fill, snippet, and behaviour with/without customisable summaries
Jul 20 2020
There are three sub-issues here:
- Stripping interwiki prefix.
- 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?
- Unnecessary piping. May be required for VE to WYSIWYG. It’s a disservice to those who prefer clean source, but what could be done?
Jul 14 2020
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.)
Jun 21 2020
Jun 15 2020
Jun 10 2020
Should step 1 be "Create Template:Main Page/minerva.css with ..." ?
Jun 9 2020
This task is publicised in Tech News 2020, issue 24.
Jun 3 2020
I got this on sup and span lang whilst making a visual-editing reply at diff 426998, described in post vnjnk29hmsb98r71.
Jun 2 2020
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".
May 8 2020
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.
May 6 2020
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
Apr 25 2020
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.
Apr 20 2020
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.
Apr 17 2020
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)
Mar 3 2020
Mar 1 2020
Jan 21 2020
If the decision is "no bug fixes for such old devices", then fair enough. Just wanted to report that the issue exists.
Nov 7 2019
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).
Oct 11 2019
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.
Oct 8 2019
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.
Oct 6 2019
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:
Oct 4 2019
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.)
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.
Sep 26 2019
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.
Sep 25 2019
Sep 24 2019
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?