Good call on planning for multilingual questions. What are the plans for specifying language targeting (i.e. in which language projects or for which users/browser languages the survey will be shown, and in which not)? Realistically we won't have translations into every language, and showing the question in English to readers in other languages (or using the fallback chain) should be avoided.

Also, what about project targeting? (Some surveys might only make sense on Wikipedia, not on say Commons or Wiktionary.)

In general, there seem to be some parallels with CentralNotice. Take a look at how CentralNotice's campaign interface handles targeting by language, project and country: example.

And to expand the comparison: CentralNotice has been used for many previous user surveys, and it might be worth spelling out why we are building a separate thing here. Right now I can see the following aspects:

• The ability to show questions and answer options directly on the site (instead of on a separate survey site like Qualtrics that a CentralNotice banner links to) - however some of that might be possible within (mobile) CN banners too
• The ability to position the survey question at an arbitrary place within the page (I assume - how will we be able to specify that?), instead of the predefined CN banner slots.
• ... (fill in here)

CN will retain the advantage of more mature translation support. It integrates the translation system on Meta-wiki, which makes it easy to have the existing translation community of volunteer Wikimedians help with multilingual surveys. WikimediaMessages relies on translatewiki.net, and requires interfacing with the translator community there if timely translations are needed.

@Tbayer Project targeting will be done by overriding the configuration of the extension per-wiki initially. If it proves inefficient we'll think of a better way of handling it.

Regarding language, we'll get the messages from the UI language the user is using, which I suppose will follow up the fallback chain if those messages do not exist on such language. I've talked to @dr0ptp4kt about the fallback languages and he mentioned that we'll wait until the survey messages are translated to most languages before enabling a survey, but still there may be languages where the values have not been translated. @dr0ptp4kt suggested not showing the survey if the values come back as a fallback. I still have to dig in and figure out if we can request messages without using the fallback mechanism and know if any of them don't have a translation. (<- @Jdlrobson can we do this?)

The CN campaign interface is very nice. Right now we're going lower level, so for the first stage defining surveys will be editing a configuration file on the code repo. It would be very interesting to think about merging these functionalities into central notice, so that we could provide the aditional features to it and take advantage of the already built tools for the campaign interface, etc.

We should meet with a few people to clear out feasibility, pros and cons. For the moment we're going to develop this, but we're totally opening to merging with any extension where this would make sense, and seems like CN is a great candidate. cc/ @dr0ptp4kt Should we make this meeting happen?

I can also see the parallels, here's a few things this would do that CN doesn't seem to do now:

• Positioning "in article". Less intrusive, users will only see it when they scroll down.
• Custom question + answers banner.
• Low level per-wiki extension, total flexibility to override completely per wiki what we want to show.
• Non-wiki(p/m)edia sites specific. Extension should be usable from 3rd party mediawiki installs.

• The ability to position the survey question at an arbitrary place within the page (I assume - how will we be able to specify that?), instead of the predefined CN banner slots.

For the initial stage we're going to target post-lead-section in an article, but yes, you could see it extending to a config option so that you could target different areas in the page if it is something needed.

Thanks for all the comments @Tbayer, we should've talked before this started, let's see if we can catch up with the reading minds that envisioned this feature to try and execute it the best we can.

We should meet with a few people to clear out feasibility, pros and cons. For the moment we're going to develop this, but we're totally opening to merging with any extension where this would make sense, and seems like CN is a great candidate. cc/ @dr0ptp4kt Should we make this meeting happen?

@Jhernandez - yes, please. Next week or the week after at a mutually available time. Please ask Sarah if help is needed coordinating.

Change 229989 had a related patch set uploaded (by Robmoen):
Example QuickSurvey config and expose enabled surveys to browser

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

Disabled surveys are not sent or accessible from the browser

Our configuration is publicly available, and I can easily navigate my browser to noc.wikimedia.org, so this requirement doesn't make any sense. By "from the browser" do you mean "from the MediaWiki user interface"?

I merged the patch but the message does not get translated before being shipped to the client so I think more work is needed.
When I inspect the shipped survey I am given
question: "ext-quicksurveys-example-internal-survey-question"

but there's no way I can know to ship "ext-quicksurveys-example-internal-survey-question" with the payload..

Change 229989 merged by jenkins-bot:
Expose enabled quick surveys in the browser

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

@Legoktm I know, that ac is because we don't want to be sending through the wire what can potentially be a huge configuration, but only the bits necessary for the JS UI to do it's job. It's not trying to hide sensitive info or anything like that, it's about being more efficient and doing more on the backend to lighten the payload to the client.

@Jdlrobson there's two ways we could go with it. Either return the survey already localized from the server or get the config and then ask for i18n'd labels with a different request.

If we can reliably know the UI language of the user at server time, I'd prefer sending the localized survey to the client to avoid extra ajax calls. I'm leaving the technical details to you folks.

In the spirit of lightening the payload/processing that the client has to do, let's translate/parse the messages on the server side.

Also, if we were to do it on the client-side, then I think we'd have to create per-survey modules so that we can deliver the messages to the client when they're needed. It's not a lot more work, but it is more work.

Also, wiki links (i.e. Privacy link) need to be converted to HTML anchors.

So who's going to pick this translation up? The sprint is almost over :)

@phuedx +1 Parsed on the server, payload would be reduced by only sending the needed survey modules to the client. Seems we could register modules and their i18n messages for enabled surveys via hook.

@Jdlrobson, This just needs en messages?

Change 232210 had a related patch set uploaded (by Robmoen):
Register enabled surveys as RL modules via hook

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

Change 232283 had a related patch set uploaded (by Jdlrobson):
Register enabled surveys as RL modules via hook

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

Change 232283 abandoned by Jdlrobson:
Register enabled surveys as RL modules via hook

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

Change 232283 restored by Jdlrobson:
Register enabled surveys as RL modules via hook

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

Change 232210 abandoned by Robmoen:
Register enabled surveys as RL modules via hook

Reason:
Cherry picked to I8ab993130bf3fe60de461ecdcff66b494281c310

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

Change 232283 merged by jenkins-bot:
Register enabled surveys as RL modules via hook

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

@phuedx @rmoen I've installed the extension for signing off. How should I verify this is working?

Change 233434 had a related patch set uploaded (by Phuedx):
Enable the internal survey

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

Make sure the QuickSurveys extension is enabled; then

cd /path/to/QuickSurveys
$ git review -d 233434

and then load a page. Check that mw.config.values.wgEnabledSurveys is present and has the internal survey in it in your browser of choice.

You know what I meant…

Change 233434 abandoned by Phuedx:
Enable the internal survey

Reason:
No longer needed.

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