@TheDJ I can see that, but closing a task that's not fully resolved is also disruptive. Feel free to make T411605 the "suggest" task or whatever but please don't close this as resolved, because it's not.

I will update the task description to reflect what was done. You can file separate task with any further work if you like.

The "accept" part is resolved, but the "suggest" part is not.

Thanks for working on this! However, it's unfortunate that in LivePreview, the unaltered page is downloaded and the error is detected only front-end, which partly defeats the point of the wish because we still have to wait for the entire page to be downloaded before we see the error. Couldn't the API be made to return an error instead of text if templates doesn't include templatesandboxtitle?

add brand new classes for links that looks like user links in content areas, with equivalents for the all different types of user

This seems like the obvious way to go.

At the very least please get rid of "proposed by". It unduly emphasizes the submitter when wishes should belong to no one but the community. In enwp's terms, it's WP:OWN.

I find the display both intrusive yet easy to miss, so I just did .ext-communityrequests-entity-talk-header { display: none; } and kept my script running on talks. The placement, color, padding, and verbosity all facilitate banner blindness. I didn't even notice it the first time. And once I did it was not easy on the eye. I think it should be the title only and placed in the vicinity of contentSub.

In T406957#11389344, @MusikAnimal wrote:

In T406957#11388367, @Nardog wrote:

I hope the title will link to the main page ([[Community Wishlist/W...]]) when the list item is about a subpage, talk page, etc. I made my script do this and I've found it useful.

Couldn't that be adverse to patrollers? The linked page should be the page that was actually changed, I think. I was nervous even showing the wish titles in recent changes.

As a patroller scanning titles on recent changes, at quick glance you'll see the wish titles stand out as if they were actual titles. The descriptive and sometimes lengthy names may appear like vandalism or nonsense pages. This isn't a problem on Wikidata because most of the editing is done to entities, so recent changes patrollers are used to going by labels and not page titles there. It's possible to only show the wish titles for watched pages. I was considering doing that, depending on how reception goes. Patrollers may only care about the actual title, while page watchers would more likely prefer the entity title.

We also need to keep in mind the extension may eventually be used on other more content-focused wikis, so the aforementioned problem may become more pronounced. If it comes down to it, we could introduce a preference or something.

I find this intrusive and ugly, inhibiting the reading experience. If it's how it's going to be implemented, I'll keep using the edittop gadget, which defeats the whole point of this task viz. to make the gadget redundant.

What I'm saying is that the edit summary shouldn't contain English words that part of the user don't understand.

I have news for you: The source of virtually any wikipage that's not in English contains—if not is littered with—English words. Sure, magic words and template names and parameters can be translated, but they frequently are not, and HTML(-like) tags can't be translated at all. Not to mention many punctuation characters in the ASCII set are culturally specific to Europe/anglosphere. (less tech-savvy East Asian users are frequently confused when full-width characters don't generate code). /* top */ is code that generates a link to #top, which is in the HTML specs. That's no different from <b> or <span> or class=. If you think top should be translated then you should think those should be translated too (which I don't). If you think you're doing non-English speakers a service by translating it, I find that naive and short-sighted.

There shouldn't be any non-localized strings in the interface :)

It's a string that's seen by users, and it'd be much better to translate it. They don't care that HTML has some internal feature for linking to #top, and would just see some randon word that sticks out from its surroundings:

The above patch for Vector is a bit of an exploration of what it'd be like if the edit link(s) were added at the top of the first paragraph on a page and then floated to the end of the line, e.g.:

It's not yet ready for review, and perhaps doesn't even belong in Vector.

Good idea to add #top, bad idea to translate it. #top is part of the HTML spec so translating it would be confusing.

Can you extend this to subpages, page history, WhatLinksHere etc. (i.e. wherever there's wgRelevantPageName), and the Translations: namespace?

I hope the title will link to the main page ([[Community Wishlist/W...]]) when the relevant link is to a subpage, talk page, etc. I made my script do this and I've found it useful.

The behavior I expect is diff= has no effect, i.e. https://en.wikipedia.org/w/index.php?title=Foobar&diff= is equivalent to https://en.wikipedia.org/w/index.php?title=Foobar.

If the template was not used, we could hide the preview HTML by putting it in a collapsed box. Or we could just not display it at all. Is there any use case for seeing the HTML when the template being edited was not used?

I don't think that's necessary at all because there's Template:Int anyway. In fact mw:Help:Extension:CommunityRequests#Data parser function says lang is "only applicable for the title field"!

Scratch the last point, even if you could use a tag the challenge of keeping track of which vote is being replied to remains, my bad. Now that I think about it, the new section should still show the comment being replied to. The user would be much less likely to remove the parser function if it turned into basically {{talk quote|<original comment>}} after preview/save.

Perhaps we should show it only when the user interface language differs from the site language.

Pppery is a sysop and translation admin. The problem is that his edit didn't stick after your edit with the form.

We'd have to load the wikitext of the talk page and I guess cache that aggressively to avoid it being queried on every pageview.

I've assumed caching on every save/purge rather than every pageview is how {{#CommunityRequests:wish/focus-area/vote}} already work. It's not?

Well, consider this task contingent on the voting section only accepting supports. That is, as long as it accepts only supports, these things should happen in order to make it less confusing, but that's not to say it shouldn't be opened up for replies and opposes.

Linking to the FAQ also makes sense, but we'll have to add a configuration setting for it because that page is not part of the extension, rather just a page on Meta-Wiki.

The more I think about your reply the more absurd it sounds. You're also describing a problem that would be a problem just once per user, even if such a person actually existed. I'm describing a problem that persists and potentially becomes worse as I get older.

Then disable them only when the focus is inside the summary or title field (which I never use because I've disabled the new topic creation and hidden the summary field). That is such a bizarre argument. I've just described actual harm it causes that I experienced and all your points are vague and hypothetical.

Self-declining in favor of T407086: Make edit summaries more specific, feel free to reopen.

The title and acceptance criteria only partially address the problems identified in the description (which was copied from my comment on wiki with no attribution). Perhaps you should stop allowing comments while supporting.

If this was solved not by disallowing early votes but by allowing them officially (but hiding them until the wish is accepted), it would not only benefit participants who would no longer need to remember which wishes under review they intend to vote for, but also you who would now be able to review wishes more easily by seeing which wishes have attracted more votes.

<span> should also be removed from API responses.

I wrote this on [[Talk:Community Wishlist]] but it's germane here too: I for one don't understand why we can't vote for wishes under review. It adds the burden of having to remember or make notes of wishes you intend to vote for. Why not just hide the votes until the wish is accepted... It might even facilitate the review process since the numbers of support votes would indicate which wishes have merit.

I would add another acceptance criteria that the author of a wish won't be able to remove their support.

There should also be a parser function to retrieve the vote count for a particular wish or area.

Are the :set... methods not chainable?