I've started T365471 talk about the next steps here. I think this task can be resolved as the form uses i18n messages and can be localized (how that's done is not quite clear yet).

In consultation with @KSiebert I've made the above changes. This is now ready for QA.

What is the expected behavior supposed to be for logging out and logging in? Shouldn't I get some kind of warning if I'm over or under the character limit along with the Submit button staying disabled?

Sorry, I sould've linked. You can use the patchdemo: https://patchdemo.wmflabs.org/wikis/daa3db7f2e/wiki/Community_Requests/Intake

@JSengupta-WMF You might want to look at the vertical spacing of the form fields (especially the top of the form), I was slightly guessing (but figured it'd be caught in the design review later).

I think the last part of this that isn't either already done or captured in another task is the file-uploading. Do we want to do anything for uploading? I feel like it might be a bit outside the MVP scope. But let's start a new task if it's something we want to add (e.g. I was wondering if we should limit it to screenshot uploads, forcing the use of the wikimedia-screenshot template so if anyone uploads something else it can be more easily found and deleted — but we'll have to commit to monitoring the uploads, I think).

Regarding adding 'unknown' to the wish type: currently 'feature' is selected by default, but I imagine that we want a) none to be selected initially; and b) it to be a requirement to select something (now that 'unknown' is to be an option). Sound correct?

This is done, and there should now always be a way to add a new item when the dialog is shown on pages that are not yet linked to Wikidata.

This is done now.

Should the table and field API params be marked as required?

Note that the usual edit message on Meta is wikimedia-copyrightwarning:

I'm not sure why, but the checkbox doesn't always work for me. Sometimes the "Submit wish" button stays disabled.

I think all the remaining work here is captured in subtasks. This could move on to QA, but perhaps it's better if each subtask does first.

@JSengupta-WMF do you want to add any design notes here?

Stalled on T361554.

@JSengupta-WMF Terrific, thanks. Done.

@JSengupta-WMF Is the part here about disabling the submit button correct?

I've added banana validation to CI; MR ready for review.

The index pages are going to be one per focus area aren't they? And the focus areas will be dynamically definable by e.g. creating a page with a {{Community Wishlist/Focus area}} template (with other metadata such as descriptions)? All of which is pretty much like the old categories system.

I was wondering if the ChipInput had been considered for this field? It could accept Phab task ID or URL, and display the task ID in a chip. That'd be smaller than the full URL, and we'd not have to implement the add/remove logic. But perhaps this was all thought through before, in which case no worries and I'll carry on with the designs as they are, with URLs! :-)

Oops, sorry, I missed T363221: Encourage users to log in: wish form.

In T362761 it mentions that "The user should be logged in to create a wish." Will we be enabling the gadget as default for all users, or just some? We could do that when deploying, e.g. by adding |rights=autoconfirmed in the gadget definition.

Although actually, perhaps that and the other remaining fields listed in the description above should have their own tasks? Adding VE is certainly a separate chunk of work, and project is already T362275. I'll update the description.

The next part of this that I would like to look at is how to read and write the list of phab tasks. I'm imagining that we'll want to have a comma separated list of links, as it has been in the past, e.g.

I'm not sure I understand. The language selector is for switching to other language versions in the same project — but MDwiki only has one language edition doesn't it? i.e. de.mdwiki.org isn't a thing. So you'd want the language list to somehow know that you want to link to Wikipedias, rather than say Wikisources, but I'm not sure how it could.

Yep! Thanks.

PR for WS Contest: https://github.com/wikisource/wscontest/pull/69 (not ready for merging because it references the symfony7 branch of the bundle).

PR for upgrading to Symfony 7: https://github.com/wikisource/wscontest/pull/69

I'm working with tool-wscontest and WS Export as example tools for upgrading, to ensure I upgrade the bundle correctly.

Main Pages will now be able to add the __EXPECTWITHOUTSCANS__ magic word to be excluded from Special:PagesWithoutScans.

@Samwilson Is there a way to test this intake form right now for QA? If so, how? I'll move this back to In Development for now. I can move it back to QA if there is a way, thanks!