Actually, my assumption above is wrong isn't it? We do want to include the title parameter in the template, and have it be independent of the page title, because it'll be translated. The page title will (I think?) always be in English, but could be different to the Wish Title either for clarity or translation purposes, and so there's no need for the intake form to worry about renaming the page if the Wish Title changes.

For T362761 I'm experimenting with how to load the form for a given page (or a new page). Currently wondering if it'd be good to an action entry point to the form, so that e.g. /Wishlist_Survey/Propsoals/Lorem_ipsum?action=wishlistedit can be used to edit or create the Lorem_ipsum page. The issue I'm wondering about is how to handle the Title field, given that it's part of the page name — if we allow it to be edited (other than during the initial proposal creation) then we'll have to implement a page move etc. as part of the proposal-saving process, and this feels a bit complicated.

If not a search form directly in the dialog, we could link to the search form or results on Wikidata. But I do think a search form would be useful (many times I've been using it and wanted to change the search terms).

❌Issue-Safari is having an issue when clicking the AutosuggestSiteLink the first time. It just hangs until you push it a 2nd time as seen in the video below.

@Tacsipacsi You're right about these things, but one of the design goals we've got for the new intake form (and other components of the Wishlist) is that it could at some point be moved to become and extension. See T363374 for some more details about that.

Fixed. No need for QA I think; this is a developer-only issue.

If you need to unbreak the tests

Yes, I think so, that sounds a fair bit simpler. The extension is already requesting the actual OCR data, so some config data should be easy to do.

Merged and deployed.

Bundling all languages together is probably the easiest, but you're right it's not very efficient. A couple of things that seem useful to me:

A similar modifiable search form is used in #tool-wikidata-todo, e.g.: https://wikidata-todo.toolforge.org/duplicity/#/article/enwikisource/Author:Dennis%20Feltgen

This task is about internationalizing the intake form isn't it? Making the labels etc. available in the user's interface language. I wonder if being able to "submit their response in their native language" is a separate matter and should have its own task? That seems like we'd be having to figure out how to save data (T362761) and put it in the right format and location for the Translate extension to work. (E.g. with a base language other than English? Or by inserting the provided text as the other language and adding the English version ourselves? The latter is how we've done it for previous surveys.) But yeah, should this task stay scoped on the i18n of the form?

This has been added to the tool and deployed. See it at https://ocr.wmcloud.org/?engine=transkribus&langs[]=la-in

@JWheeler-WMF Do you mean you don't think it should be removed when the dialog is in the "information-only" state?

The bigger issue (maybe?) is that on Meta, only admins can change the content model of a page. At least for the mainspace, .json pages are by default wikitext.

Discarding for sections should be working correctly now.

@MusikAnimal In the planning meeting we wanted to create some more tasks for the Intake form; hopefully this is on track. Lots of the details not yet defined; please change as you see fit.

Should this ticket move to the Language team?

Is there actually anything more to be done for this task? The current project page needs to be made not-a-draft and marked for translation perhaps, but its content seems okay to me (I'll try to add some more about the recent developments to the gadget).

@IKhitron eek yes! I can't reliably reproduce this, but have been able to a few times. :-( I'm thinking that it's related to how we're deleting the record by looping through all records and finding the matching one; I've made a patch for that (hope you don't mind me jumping in here @TheresNoTime).

aaah... I feel a bit silly. It would appear that we've never been able to discard data for a section: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/965051/11/resources/src/mediawiki.editRecovery/edit.js#92

All done now I think.

This issue has been fixed as part of other work around section-saving.

Oh, actually, the create account link should probably be conditional because account creation is not always open. Does that matter?

So you need also to check whether edit recovery is enabled by default.

The 'no results found' state should perhaps keep the submit button, because after T362592 is done there will be something to submit (or at least the user has the possibility of changing something that'll enable the submit button). So it's just the 'already linked' state that shouldn't have the submit button, it looks like.

Good point about the unnecessary submit button. I've created a task: T362591: Remove submit button when nothing to submit

Are the following error messages suitable?

This could be done by only saving the preferences when the config popup is closed.

Thanks @GMikesell-WMF, I think most of these issues are resolved now, could you please test again? Thanks!

Last parts of this done in https://gerrit.wikimedia.org/r/c/mediawiki/skins/Foreground/+/1019248 (thanks @thiemowmde)

Is this still an issue, after the recent work? (I don't have Safari so can't test.)

@GMikesell-WMF It looks like there might've been a few issues here:

• We were saving the page text even if it wasn't changed; this is now fixed.
• Clearing the page data after saving was ignoring the section number; this is also now fixed.
• Lastly, it appears that sometimes browsers' dev tools are showing the contents of the database prior to the last updates, so it's probably best to use Special:EditRecovery or click the 'reload indexedDB' button (although perhaps you were and this is not an issue).

Regarding pre-caching of OCR: we actually attempt to do this already. When the OCR button is clicked while editing, the following page is also requested and cached for an hour — the idea being that when you then go to the next page and click OCR it'll be nice and quick. However, it appears to not be working!

Okay, so it sounds like we can enable live diff for the show-changes button in the ER notification, and that does solve the bug. My point above was about also enabling it for the normal preview button, regardless of whether the user has enabled live preview; that's the unexpected bit, perhaps. If we enable it only for the notification button, then we still have the problem of what to do for the normal button when non-live preview is enabled.

The issue was with the lack of support for the quantity type. Added now. Will release a new version forthwith.