This is not urgent, but would like to do it by July 5.

It should just read "Other".

We'll need a new translation string, unfortunately. Our current policy is not to merge code that requires new translation strings on Friday/Monday/Tuesday. If this could wait to roll out with the train on July 18, there would be enough time for the translations to be merged using normal processes.

For the third question about topics of interest, the typeahead menu should not allow users to add their own responses -- they should only be able to choose from the list that pops up. Does this change have a particular effect on no-JS users?`

No JS users won't see a textfield at all, they will just be able to check the existing boxes.

@kostajh and I discussed, and we will try to get the new string translated in time tomorrow morning.

@kostajh -- is that the way the behavior has always been for no JS users? Just the checkboxes and no way to add anything else?

Change 521353 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] (wip) Make freetext responses in welcome survey feature flagged

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

Change 521385 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Add i18n messages for non-freetext "Other" option

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

This patch does cause one display issue with variation C (the WelcomeSurvey popup), but since that's disabled in production right now I don't think that that's an urgent problem.

Change 521385 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Add i18n messages for non-freetext "Other" option

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

is that the way the behavior has always been for no JS users? Just the checkboxes and no way to add anything else?

No JS users saw checkboxes and a freetext field in which they could enter comma separated values:

Change 521353 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Make freetext responses feature-flagged

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

Change 521490 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Add tests for freetext test feature flag

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

@kostajh (and @MMiller_WMF ) users are still able to enter text in "Add more topics..." which causes display issues:

• if no topic gets selected and only freetext entered, then the first available topic ("Entertainment") would be entered, the user-entered text would be discarded.
• if one (or more) topics were selected (none of them is "Entertainment") , then the result of adding freetext would as in the case above: user-entered text would be discarded.
• if a selected topic is "Entertainment" and a user enters text, then the entered text would be marked as red.

if a selected topic is "Entertainment" and a user enters text, then the entered text is marked as red.

Seems like we may need [allowDisplayInvalidTags](https://doc.wikimedia.org/oojs-ui/master/demos/index.html?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop#TagMultiselectWidget-inline-input-allowed-values-foo-bar-baz-allowDisplayInvalidTags) to make this more clear to the user

For a quick comparioson between disabled free text: betalabs and production.

betalabs	current production

I agree with @Etonkovidova that the automatic selection of "Entertainment" should be fixed. I think the best interaction would be if a user enters text that isn't allowed, it shows in red and disappears when they click away. Is that possible?

Change 521490 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Add tests for freetext test feature flag

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

I agree with @Etonkovidova that the automatic selection of "Entertainment" should be fixed. I think the best interaction would be if a user enters text that isn't allowed, it shows in red and disappears when they click away. Is that possible?

This is how MenuTagMultiSelectWidget works when "allowArbitrary" is set to false. Try going to the demo page and type in "blah" then press tab; the first item is entered. I'll file a task with OOUI to see if it gets fixed in the library.

• The translation to Korean seems to be done - MediaWiki:Welcomesurvey-question-reason-option-other-no-freetext-label/ko
• The issue that was reported in https://phabricator.wikimedia.org/T226039#5318015 was filed by @kostajh as T227666
• important - the major issue remains: it's not possible now to add freetext in 'Add more topics'

@MMiller_WMF - can we just disable that field entirely or to change the label text to "Click and select additional topics of interest"?

I see that @matmarex has already merged a fix, so I'll wait for that to be in production with the next train before resolving this task.

Assuming that an OOUI release happens this week as usual, the fix will actually be in the second-next train (23-25 July rather than 16-18).

@matmarex - yes, the issue in T227666 seems to be fixed.

Moving to PM Review column to be checked after deployment.