Do we want to warn people as soon as they enter a duplicate title? Or append the -1, -2 etc when they submit? Also, is that a hyphen, or should it just have the number appended to the title?

@JWheeler-WMF Just to confirm that the two post-edit messages should be a) "Your wish has been submitted." and b) "This wish has been updated."?

This overlaps with T367937 a bit. I've made a patch that fixes both I think.

I started making a patch for this, but I'm not sure everything's clear. In a Codex field, helper text is never hidden — do we want to do the same here? In fact, is there a plan to use Codex for the installer?

That task is done, and I think there's some more work to be done here: the table should be displayed in the content language, but we're handling the sorting according to the interface language (e.g. Wishes/en?uselang=ar shows the sorting arrows on the left, and Wishes/ar?uselang=en shows them on the right; both are incorrect).

The help links should probably also have cursor: pointer.

This is all merged and deployed on the test site now, and ready for QA.

This is for $wgUseCodexSpecialBlock = true;, where the pre-fill values don't yet work.

Thanks for testing! I forgot that this was dependent on T368578. Stalling now pending that task's resolution.

That's what I was thinking. Sounds like this needs to wait till that's done.

MusikAnimal fixed this yesterday in !102. The test site has been updated with the latest code.

It looks like this is because we're overriding the padding on table headers, from the default of 21px provided by the jquery tablesorter plugin. Patch on its way.

@JSengupta-WMF Yes, that's correct. For now we'll send people to the normal wiki search results page.

Yep, I think that's the simplest way. And do we need to change the button to be of type submit as well?

It's normal for HTML forms to be submitted when the enter key is pressed while focus is in a text field (note, note a textarea, nor I think any other types of field). But this can be changed, so we don't necessarily have to make it submit it. We could also set the enterkeyhint attribute, which would help mobile users know what would happen (doesn't help desktop, as far as I can tell).

@JSengupta-WMF just checking, did you want the form saving button to be "Publish page" and "Publish changes"? Or was it "Publish wish" and "Publish changes"?

@tstarling This might be a bigger bug: how does the bot protect against processing translation subpages? It looks like it's treating each (/en, /en-gb, etc.) as a separate wish:

After more discussion, it sounds like we don't actually need the subpage to be created for wishes, because all discussion for them will happen on their talk pages. That means that the wish page itself can be marked for translation.

Oh right, yep: /Translatable is what we're using for Focus areas, so we should use the same for Wishes I think.

A few things I'm not quite sure of here:

@GMikesell-WMF Thanks! And Timeless is now installed, so you should now be able to test it, e.g. https://wishlist-test.toolforge.org/wiki/Community_Wishlist/Intake?useskin=timeless

Am I seeing the correct behaviour here? If I manually add random other project names in |projects=, they don't get removed when editing and saving via the form. Should we be deleting them, as they don't appear in the form?

We can add an InputBox search field, that'll send people to the normal search results (limited to Community Wishlist/Wishes/ prefix). That wouldn't live-filter the table, but would be simple to implement and might do as a short-term workaround for now.

Good point. I've made a MR for that.

As this removes any navigation while creating a wish, I think the Cancel button should be added here as well, so that it's possible to open the new-wish form and then leave it again without submitting.

The multilingual wikis use i.e. name-wikifunctionswiki so the string interpolation wouldn't work. We can of course just add a switch statement in the template/module and do as you say. I'll look into it.

(I left this comment on the above MR, but should've made it here.)

I think @tstarling's idea here of using ?commreqaction=edit to trigger the form is probably the easiest, as it means we don't have to hack any of the links. It won't touch the new-wish workflow (that's a separate task).

I think everything is done here. Thanks @MusikAnimal for doing all the work!

The form removes any invalid input after the user submits. It might be nicer to do this before a user submits, letting them correct any mistakes they have made. Otherwise, they might lose data.

You're right, it seems a bit tricky to even find the code! Is this it? https://github.com/hallowelt/mwstake-mediawiki-component-commonuserinterface/blob/6689afbadd49e65ea72c5f9dc02b920478262332/src/Hook/MWStakeCommonUIRegisterSkinSlotComponents.php (That repo should probably be added to codesearch?)

Perhaps the TalkBelow extension would be an alternative?

I've switched it over to ocr-prod02 now, and shut down ocr-prod01. The latter can be deleted in a day or two.

I'm not quite sure what you want on the list, but does https://commons.wikimedia.org/wiki/Category:Translation_possible_-_SVG_(switch) (and other similar categories on Commons) help at all? Or are you looking for technical information about what SVG structures are able to be translated?

https://ocr-test.wmcloud.org/ (on ocr-test02) is done and working. I've got ocr-prod02 all setup and ready to go, but will wait till the URC+8 morning to switch over to it, so I'm around for the rest of the day to monitor it.

The tool is working fine on PHP 8.2 now, so I think we're good to go ahead with switching to a new VPS. I'll start with http://ocr-test.wmcloud.org/ and follow (and update) the docs.

The OCR upgrade is tracked in T332611.

Pretty much everything here is done now. If anyone else would like an account, please let me know.

Yeah that does make sense! Go for it. (I'll now return to staring out a train window.)

I thought we'd already gone down the path of Option 1? We've got the patch ready to go for WikimediaMessages (as soon as they're stable enough to send for translation), and those messages are already being used in the gadget. (Although I've been out for a week so might not be on top of recent changes.)

It sounds like a decision has been made here to not add mw: by default, and replace all occurrences of it in messages with full mediawiki.org URLs. Is that correct? Should T240811 be declined?

@RoyZuo A workaround that you can use now is to delete your PHPSESSID cookie for ocr.wmcloud.org and try again with the ?uselang=en URL parameter.

No, this is a software bug I think. :) It should be possible to switch languages using ?uselang=xx as is normal in Wikimedia software. It defaults to whatever your browser sends as an Accept header, but it should still be possible to change it. We haven't implemented a UI for switching the lanugage (which should also be done!) but it should still be possible to switch using the URL parameter.

This is not Bug Report.