The Community Tech team has discussed this request, and we unanimously feel that it’s beyond our scope. Here’s why (according to analysis from the engineering team): PageTriage, while a useful extension, is written in a way that’s completely based on English Wikipedia processes. In order to convert the extension to work on other wikis, the extension would need to be adjusted — not only for other processes, but also to have a configurable process definition that each wiki could define for itself, based on each community’s needs. Consequently, this request would require a slew of analyses and decisions, such as: what it means to tag an article for deletion (e.g. what pages messages goes to, what templates are used, if there are follow-ups the system should be aware of, etc), the way we tag articles, which articles show up in the queue, and more. Moreover, we couldn’t easily trim down the scope by disabling some features. The internal workings of the extension are deeply intertwined with English Wikipedia. We would still need to do a significant amount of development work to ensure that the behavior remained stable and useful to other wikis. For these reasons, this request is unfortunately too big, so we cannot take it.

We've reached a decision: the final wording will be in my message above (where you can find #1-7, written out). Note that #1-4 are user-facing, and #5-7 are not for general users, as the messages would typically be found in the MediaWiki API documentation page or the API sandbox.

Update: We have decided to set the pointer-events to 'none.` This means that the click event will applied to whatever is behind it (which, in this case, is the button itself -- and, thus, would open the fly-out).

Thanks, @dom_walden. The "whitespace" related requirement simply meant that, with these changes, there should still be whitespace between the article title and the top of the article (which is now where the information bar ends).

• I've updated the proposed messages above to only state "New Pages Feed" (rather than "page curation feed" or "page curation queue"). Thanks for that clarification, @MusikAnimal.
• I've updated the confirmation message above to more explicitly ask the user a question, as per the suggestion of @Prtksxna.
• Regarding the API Help message suggestions, as stated by @DannyS712: I'll leave these decisions up to @Mooeypoo and other technical folks. Thanks!

@DannyS712 The Community Tech team is currently only focusing on Page Curation updates that were part of the 2019 Community Wishlist. However, if you're interested in further Page Curation improvements, requests can be forwarded to the Growth team (which typically manages Page Curation) or canvassed for the 2020 Community Wishlist. Thanks!

@Barkeep49 Thanks for verifying. Yes, the processes have been completely decoupled, so each action (i.e. reviewing and sending a note) would need to be triggered separately. I'm marking this work as resolved, as we've now verified the behavior (as described in the requirements) on production. Thanks!

Thanks, @Barkeep49, for the update. In that case, the changes should all be live and ready to test. Can you let us know if these changes are working as expected on production, when you get a chance? Thank you!

Pinging @MusikAnimal, @Prtksxna, @Barkeep49, and @Insertcleverphrasehere to see if they have any feedback, based on the request from @MaxSem (see above). I have written out how we can potentially rephrase some of the language to make it more clear, but I would love some feedback from other people. Below are the sections that Max has requested that we review:

Thank you, @DannyS712!

This work should now be on production. @DannyS712, can you verify that it is working as expected? Thanks!

@Prtksxna -- No, it's no longer needed. Thanks!

I've discussed the "Contact Us" question with @Prtksxna. We talked about the fact that: a) bug reports & issue outreach on the general Talk page aren't ideal (because they may clog the page with redundant content), and b) bug reports on Phabricator aren't ideal (since not everyone has Phabricator accounts, which may discourage users from reporting issues). As a middle-ground solution, we've talked about perhaps redirecting users to discussion on-wiki, but in a distinct section/heading that doesn't muddle the general Talk page content.

@Prtksxna We would like to inform the users that they need to login to Commons first in order to upload translations to SVG Translate. Any recommendations for how to do this? Thanks!

I'm also wondering what's the best avenue for "Contact Us."

@Barkeep49 Thanks for the update. I just responded to the question on WT:NPR. I hope that I sufficiently answered the question -- but, if I did not, I'm happy to elaborate. In that case, I'll wait for an update regarding implementation of the template or any other questions posed by the community.

Thanks for the thorough QA testing, @dom_walden. Also, great point about the possible UI issue (i.e. clicking the mail icon doesn't open the "Page info" flyout). While I don't necessarily see this as a dealbreaker (since the user isn't blocked from accessing the flyout), the combination of blocking so much space & not having any direct functionality (other than informing the user of Talk page updates) is a bit awkward. With that in mind, I have a quick question for you: Does clicking on the other icon (i.e. the count of potential issues) result in opening the "Page Info" flyout? If not, I think the lack of functionality for the lower Talk-related icons is probably fine, since they mirror the behavior of the above icons.

@JoKalliauer & @dom_walden Thank you for checking out the changes on production. I'll mark this ticket as 'Done.'

I removed the Community-Tech tag from this ticket, as the potential changes are not a part of the Community Wishlist Survey.

I'm removing the Community Tech label from this ticket, as this work is not a part of the community wishlist.

• I'm removing the Community Tech label from this ticket, as this work is not a part of the community wishlist.

I'm removing the Community Tech label from this ticket, as this work is not a part of the community wishlist.

@MaxSem Can you provide some details on the impact of this? Thanks.

I'm removing the Community Tech label from this ticket, as it is not part of the wishlist requests for Page Curation.

The Community Tech team doesn't have time to look into this now, so we're taking this off our board.