Editing Improvements & Changes

with the editing toolbar I’ll be showing comments highlighted on the page in editor mode so they’ll be easy to spot.

Of course, ZCEs aren’t the only things that use the %% markup. Nearly every well-established page has a comment at the top indicating the picture went through Image Pickin’, or another administrative note. So such a tool would either have to determine if the comment is in the examples list or not, or show the actual commented-out text—which rather defeats the purpose of hiding it.

Maybe some form of pop-up in the sidebar that wouldn’t clutter the page unless you need it…

Whoops

Edited by HeraldAlberich on Oct 24th 2023 at 1:28:34 PM

Actually... I would like a designated markup either for proper comments or for hiding examples. A lot of pages have a moderator notice in %% blocks, so if it used something else it may be easier later to query articles which have what warning.

Edited by Amonimus on Oct 24th 2023 at 8:55:35 PM

Just pushed up most of the changes in the OP. Check the Changelog or the Wiki Talk Changelog Thread for a full list of recent updates.

Im doing the pagination for article history pages right now. What do you think the limit should be per page? As far as i can see its either 25 or 50 on various parts of the site but wanted to know if article history should be different.

Edited by kory on Dec 15th 2023 at 9:58:52 AM

Without deeply thinking about it, I like 25. The current is 15 and not sure how much it bothers people, it depends at how often a page is edited. But with collapsible edits 50 may look fine.

I assume it will tie to linking and making it selectable may not work out.

Actually, with the now ability to "show" edit reasons, I was wondering if not preloading edits and using AJAX to get them when they're opened would help the load time further.

Not sure if I've brought this before, but "Not enough context (ZCE)" is the only one capitalized.

Edited by Amonimus on Dec 15th 2023 at 11:21:55 PM

Exciting stuff already! I hope future additions go smoothly.

The monospaced font setting still forces Courier—could it be set to the generic monospace family so that it respects the user's browser settings? I don't find Courier very legible, and my default monospaced font has features like programming ligatures that help me catch some markup errors. The workaround I've come up with requires installing a semi-obscure browser extension and knowing CSS and devtools.

Was that how it was before the font was changed to the newer one?

Related to this report

That query says “This has been a thing for a while now”, so will there be other users complaining if this is changed to something it wasn’t before?

Edited by kory on Dec 17th 2023 at 1:05:00 AM

I can't do prophecies, but maybe people who notice the change should be intervewd how it looked before and if they were using custom browser settings. I don't, so currently everything looks how I remembered it, while removing Courier to me makes it look odd.

Yes and this is exactly why we haven’t changed it. The whole point of adding the monospace filter was to “put it back how it was” because of users complaining that it wasn’t the same as it used to be. So it seems like changing it will just cause a different group of users to complain.

People getting vocal about the CSS sometimes makes me think they should be allowed to just change it themselves, like when FANDOM finds a page named User/commons.css it merges with the main stylesheet.

That's kinda getting not relevant to editing to I'll stop here.

I have a suggestion for a new edit reason to put in the default list: fixed markup. I've often had to edit a page to add an extra bracket or backtick to get the markup to work correctly.

Can I propose that the default edit reasons use proper capitalization and also propose a few links/expansions to the text?

Ya of course. What things should be changed exactly?

I'd add "Fixed one or more redlinks" and "Fixed one or more greenlinks" to the reasons — those are two of the ones I use most often.

Until next time...

Anon e Mouse Jr.

Is this a common edit reason a lot of other users will use as well? And can we merge them into one like "Fixed red/green links"?

Greenlinks are disambigs, so you can just use the "cut during cleanup" option. And redlinks are actually allowed, unless they were accidental wiki-words.

Ee-yeah... I'm so used to just using "Fixed a greenlink" as an edit reason for that purpose, as shorthand for "Replacing a disambiguated link with the correct one or cutting it if there wasn't an appropriate page to change it to."

"Fixing a redlink", at least as I use the phrase, is typically shorthand for "Fixed a misspelled link to make it a bluelink." or "De-linking an accidental wiki-word via adding the proper coding."

Until next time...

Anon e Mouse Jr.

Edited by AnoneMouseJr on Dec 20th 2023 at 5:43:42 AM

Proposing a list of changes:

• "Crosswicking" -> "Crosswicking"
• "Not enough context (ZCE)" -> "Example does not sufficiently explain how it applies"
• "Misuse" -> "Misuse of the page/link"
• "Fixing indentation" -> "Fixing indentation"
• "Natter" -> "Natter"

I would also support a "Fixed markup/formatting" edit reason as well. Several times I've fixed entire pages that had extra spaces or left out separation lines, etc.

I support these. I'd also add:

• "Alphabetizing example(s)" -> "Alphabetizing example(s)"
• "General clarification on works content" -> "General clarification on work content"

Ok gotcha. I’ll change how the buttons work and add the links to them. Not sure if I can get to this before finishing the editing toolbar, but any suggestions added in this thread over the next week or so I’ll be sure to add once that’s live if I can’t.

Wondering if these may be taking quite some space. Probably nobody's bothered by them, but if we're planning to add more, maybe the font could be made smaller or they be put into a scrollable list.