Change #1124438 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/QuickSurveys@master] Make embedElementId mandatory when embedding inside a SpecialPage

https://gerrit.wikimedia.org/r/1124438

Change #1124439 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/QuickSurveys@master] Mark ext.quicksurveys.init as stable

https://gerrit.wikimedia.org/r/1124439

I think this ideally needs the following changes:

• [required] An update to includes/SurveyContextFilter.php which permits targeting any namespace if pageIds is set. I guess this is an existing bug since a page in the Help namespace has a pageId and I assume that is currently not working?
• [required] We currently support a pageIds configuration option. Since special pages do not have page IDs we would likely need something specific for targeting specific special pages. Alternatively pageIds could we modified to accept strings AND numbers. e.g. pageIds: [1, 4232, 'Special:ContentTranslation']. Would it make sense to call a special page's title it's ID?
• [Recommended] Since quicksurveys are placed based on a heuristic based on article structure which won't work for special pages, an update to SurveyFactory to make embedElementId mandatory for these kinds of surveys to avoid non-display. I don't think this is essential though. We could just document this clearly on the extension page.

Other approach we could consider with more time:

• Providing a stable API to allow extensions to append the survey anywhere. This would be relatively simple but would mean surveys can be displayed where they were not intended. This could lead to UI problems if placed in the wrong place, wrong skin. It also means more than one survey could potentially be shown on a page at same time. I haven't had too much time to think about implications.

In T387846#10601651, @Jdlrobson-WMF wrote:

Other approach we could consider with more time:

• Providing a stable API to allow extensions to append the survey anywhere. This would be relatively simple but would mean surveys can be displayed where they were not intended. This could lead to UI problems if placed in the wrong place, wrong skin. It also means more than one survey could potentially be shown on a page at same time. I haven't had too much time to think about implications.

Just to clarify that this is currently possible by doing this (as documented on the Extension page):

mw.loader.using( 'ext.quicksurveys.init' )
    .then( () => {
        mw.extQuickSurveys.showSurvey( 'survey name' );
    } );

But you don't want consumers to use it because of the above reasons? I do think that this would be a good API to provide as consumers may want to display a survey after the user takes an action.

[required] An update to includes/SurveyContextFilter.php which permits targeting any namespace if pageIds is set. I guess this is an existing bug since a page in the Help namespace has a pageId and I assume that is currently not working?

Ack, OK

[required] We currently support a pageIds configuration option. Since special pages do not have page IDs we would likely need something specific for targeting specific special pages. Alternatively pageIds could we modified to accept strings AND numbers. e.g. pageIds: [1, 4232, 'Special:ContentTranslation']. Would it make sense to call a special page's title it's ID?

Not a big fan of mixing pageIds and Special page names. I'd prefer to introduce a separate configuration option.

[Recommended] Since quicksurveys are placed based on a heuristic based on article structure which won't work for special pages, an update to SurveyFactory to make embedElementId mandatory for these kinds of surveys to avoid non-display. I don't think this is essential though. We could just document this clearly on the extension page.

I think this should be easy to implement. I'll try it out.

Just to clarify that this is currently possible by doing this (as documented on the Extension page):

I'm not sure why this was ever documented. I think it was initially meant for testing purposes... not actual production use. I've removed it from the documentation.

The code in https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/master/resources/ext.quicksurveys.lib/init.js#L3 clearly points out that this is at least soft deprecated.

Actually thinking about this some more, I don't think this will work for our use case. We want the survey to be loaded only after certain elements in the DOM have loaded. The element mentioned in embedElementId isn't available on DOM load.

Change #1124439 abandoned by Abijeet Patro:

[mediawiki/extensions/QuickSurveys@master] Mark ext.quicksurveys.init as stable

Reason:

As per feedback recieved

https://gerrit.wikimedia.org/r/1124439

Change #1124438 abandoned by Abijeet Patro:

[mediawiki/extensions/QuickSurveys@master] Make embedElementId mandatory when embedding inside a SpecialPage

Reason:

As per feedback: https://phabricator.wikimedia.org/T387846#10601651

https://gerrit.wikimedia.org/r/1124438

Change #1124739 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/QuickSurveys@master] Audience: Allow survey to appear on configured given page name

https://gerrit.wikimedia.org/r/1124739

Thanks for your reviews and pointers. I submitted the following patches:

• 1124710: SurveyContextFilter: Remove namespace check if pageId is provided | https://gerrit.wikimedia.org/r/c/mediawiki/extensions/QuickSurveys/+/1124710
• 1124739: Allow configuration of surveys to appear on specific page names | https://gerrit.wikimedia.org/r/c/mediawiki/extensions/QuickSurveys/+/1124739

Using the above two patches, I can get the survey to appear on a SpecialPage.

But I still see two problems for our usecase (T381886):

1. We want the survey to be embedded to an element that's dynamically rendered on the SpecialPage when the user clicks a button.
2. We want the survey to be displayed every time the user sees a new automatic translation so that they can submit feedback specific to that translation displayed. Currently once a user has submitted a survey, they are not shown the survey again unless we manually call showSurvey.

I can work around 1 by adding a dummy element so that the survey is rendered and then hiding the survey until we need it to be displayed. How do we solve (2) though?

Another minor issue that I noticed is that the survey is not inserted into the embedElementId but rather after it using insertAfter.

@abi_ - what is your rough timeline for getting the surveys ready? When do you need this by?

In T387846#10606598, @ovasileva wrote:

@abi_ - what is your rough timeline for getting the surveys ready? When do you need this by?

We need the survey for MinT for WikiReaders experiment which we are hoping to release early next month so having this resolved before the end of this month would be ideal. But frankly, I'm not blocked, I can use the approach that was documented before to meet our needs:

mw.loader.using( 'ext.quicksurveys.init' )
    .then( () => {
        mw.extQuickSurveys.showSurvey( 'survey name' );
    } );

I know this is not the recommended approach; however, I think it's acceptable to use it until we create a better solution.

We could also build something from scratch specific to our use case, but that's a lot of code that need not be written.

I know this is not the recommended approach; however, I think it's acceptable to use it until we create a better solution.

I think as next steps it would be ideal if the language team and web team could talk through the options and make a decision (and document it!). Perhaps a short decision record could help? I recently did one with Niklas for WE5.1.12 and I thought that was super useful activity!

For example, if we decide it is best you take this approach I would want to make sure we've done a few things that 1) ensure the code is removed in future and 2) allows the web team to remove the code after a certain date without causing production errors or waiting on the language team. Deprecations are already slow processes right now and I don't want to be chasing the language team at some future point asking you to remove this code. I think there a few things we can agree together to avoid that.

We have a pattern of making changes as "temporary" solutions that exist years later (for example our teams added the temporary SpecialContributeSkinsEnabled in 2022 (2dfe4a9, T319240) and we're still supporting both versions in 2025. I'd like us to get better at thinking through these decisions (and their consequences) together! Does that make sense?

In T387846#10612040, @Jdlrobson-WMF wrote:

I know this is not the recommended approach; however, I think it's acceptable to use it until we create a better solution.

I think as next steps it would be ideal if the language team and web team could talk through the options and make a decision (and document it!). Perhaps a short decision record could help? I recently did one with Niklas for WE5.1.12 and I thought that was super useful activity!

For example, if we decide it is best you take this approach I would want to make sure we've done a few things that 1) ensure the code is removed in future and 2) allows the web team to remove the code after a certain date without causing production errors or waiting on the language team. Deprecations are already slow processes right now and I don't want to be chasing the language team at some future point asking you to remove this code. I think there a few things we can agree together to avoid that.

I understand your concern. Let's discuss and create a decision record.

In T387846#10612040, @Jdlrobson-WMF wrote:

We have a pattern of making changes as "temporary" solutions that exist years later (for example our teams added the temporary SpecialContributeSkinsEnabled in 2022 (2dfe4a9, T319240) and we're still supporting both versions in 2025. I'd like us to get better at thinking through these decisions (and their consequences) together! Does that make sense?

Makes sense. If we modify the QuickSurveys extension to display surveys on Special Pages and ensure they appear to all users regardless of previous participation, we can avoid using the deprecated method. So yea, lets talk to see if there is a way to do this cleanly.

Change #1124710 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/QuickSurveys@master] SurveyContextFilter: Remove namespace check if pageId is provided

https://gerrit.wikimedia.org/r/1124710

Change #1124739 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/QuickSurveys@master] Allow surveys to be configured to appear on specific page names

https://gerrit.wikimedia.org/r/1124739

I've submitted a couple of patches that should allow a survey to be displayed on any page with the given prefixed DB title.

1. 1124710: SurveyContextFilter: Remove namespace check if pageId is provided | https://gerrit.wikimedia.org/r/c/mediawiki/extensions/QuickSurveys/+/1124710
2. 1124739: Allow surveys to be configured to appear on specific page names | https://gerrit.wikimedia.org/r/c/mediawiki/extensions/QuickSurveys/+/1124739

This is done by adding a new config: pageNames: []

We just created T389104: Review quicksurveys changes so we can track code review from our side. It looks like this will be in our next sprint which starts on Wednesday, but probably will not be able to have it done until early next week. Would that work @abi_ ?

In T387846#10643086, @ovasileva wrote:

We just created T389104: Review quicksurveys changes so we can track code review from our side. It looks like this will be in our next sprint which starts on Wednesday, but probably will not be able to have it done until early next week. Would that work @abi_ ?

Thanks! That should work fine. We're proceeding with the soft-deprecated API (mw.extQuickSurveys.showSurvey('survey name');). These patches will be helpful once that API is fully removed or earlier if merged soon.

Untagging since web team work is captured in T389104.

Change #1124739 abandoned by Jdlrobson:

[mediawiki/extensions/QuickSurveys@master] Allow surveys to be configured to appear on specific page names

Reason:

Following discussion in web team, we'll reevaluate this as part of http://phabricator.wikimedia.org/T390782 and https://phabricator.wikimedia.org/T390622

You can safely use the deprecated mw.extQuickSurveys.showSurvey for your current experiment.

https://gerrit.wikimedia.org/r/1124739

Change #1124710 abandoned by Jdlrobson:

[mediawiki/extensions/QuickSurveys@master] SurveyContextFilter: Remove namespace check if pageId is provided

Reason:

Following discussion in web team, we'll reevaluate this as part of http://phabricator.wikimedia.org/T390782 and https://phabricator.wikimedia.org/T390622

You can safely use the deprecated mw.extQuickSurveys.showSurvey for your current experiment.

https://gerrit.wikimedia.org/r/1124710