Problems I'm seeing before even writing any code:

• VisualEditor requires OOUI. I don't think we're meant to mix OOUI and Codex, or at least that's going to be a hefty amount of JS just for one field
• Codex discourages using the TextArea component for source editing

I will consult the editing team.

After talking with Editing and Design Systems, it sounds like the best approach is to make the Description field entirely OOUI to ease VE integration, but at the same time mimic the appearance of Codex through design tokens. Since the intake form is relatively a low-traffic page, the extra payload of downloading both OOUI and Codex is deemed acceptable.

musikanimal opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/55

Draft: Add VisualEditor to description field

!55 adds only VisualEditor, with the intent to add wikitext editing in a separate MR. However editing/saving wishes should largely work fine.

We talked about making a new task for the switcher, but I think it's easier to just re-use the same task for now; this shouldn't go to QA until wikitext editing is supported, anyway (otherwise they have to QA twice). So once !55 is merged, we can move this back to development. And yes, I'll reach out to the Editing team as needed.

samwilson merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/55

DescriptionSection: Add VisualEditor to description field

I have filed T368011: Can't switch editing modes in VisualEditor in the wishlist intake form for the one remaining known bug. I think I need a bit more time before I can stomach trying to fix it again. Maybe someone else could have a look if they are up for it.

QA notes: for now, keep T368011 in mind with your testing. In short, don't switch editing modes :)

@MusikAnimal I find switching from wikitext editor to VE converts a link like

[[foo]]

to a link like:

[[Community_Wishlist/foo]]

Is that OK?

I find switching from wikitext editor to VE converts a link like

[[foo]]

to a link like:

[[Community_Wishlist/foo]]

Is that OK?

No! I will fix this.

musikanimal opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/124

WishlistIntake: set wgRelevantPageName on wishtitle changes

samwilson merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/124

WishlistIntake: set wgRelevantPageName on wishtitle changes

I find switching from wikitext editor to VE converts a link like

[[foo]]

to a link like:

[[Community_Wishlist/foo]]

Is that OK?

No! I will fix this.

Should be fixed now :)

musikanimal opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/131

DescriptionField: strip Parsoid IDs from generated HTML

samwilson merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/131

DescriptionField: strip Parsoid IDs from generated HTML

@MusikAnimal How much do expect/want VE in the wish form to look like VE "normally"?

Compare, for example, this table as it appears in VE in the intake form with editing the same wish with VE normally.

Intake form:

VE:

In T365157#9949450, @dom_walden wrote:

@MusikAnimal How much do expect/want VE in the wish form to look like VE "normally"?

Compare, for example, this table as it appears in VE in the intake form with editing the same wish with VE normally.

Frankly I don't think VE is acting normal here. In this example, the syntax for the template is currently broken (some of the pipes need to be escaped) so it's interpreting it in article form.

But to answer the question, there essentially is no "normal" for what we're doing, hehe. "Normal" VE editing assumes a full article context. DiscussionTools use of VE is very limited given it's intended for only for comments, so we've come up with something that's sort of new. On top of that, we're wrapping the content with a template, hence the need to escape pipes. We've done templates for the past two surveys and I don't recall an issue regarding pipes.

I'd say basic VE functionality should work, but the examples given here are stretching the limits of what even VE can do normally, I think. I would imagine anyone needing to do this level of editing is going to prefer source mode, anyway. That said, we should feel free to disable any tools from the toolbar that we deem aren't stable "enough".

Thanks for being so thorough, Dom!

Fair enough. I imported the top ~60 wishes from the 2023 survey into https://wishlist-test.toolforge.org and looked at them in the intake form with VE. I did not notice any visual bugs.

I will move this to done. Further testing may need to be done as part of T368396 and T368458.