Ok, sounds good, thanks for opening the task! I will mark this as Resolved. Thanks for all your work!

@Samwilson CSS loads when enabled or disabled of JS, as seen in the videos below. Can you review the other issue section? Is this fine or should I create a new task?

@Samwilson Confirmed duplicate entry exception when editing label to duplicate name, as seen in the video below. I will mark this as Resolved. Thanks for all your work!

@Samwilson Not sure if this is only in Vector, but the tabs do not show in Monobook and Timeless skin, as seen below.

In T407309#11429052, @dmaza wrote:

@GMikesell-WMF

❌ AC2: Confirm that only wishes with the status 'Declined' are shown.

"Declined" should be lowercase, all statuses values are lowercase. If you go to https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=declined it works just fine

Test Steps

Test Case 1: Verify MinT translation and formatting for tags field

1. Navigate to the Community Wishlist and open a wish page containing one or more tags.
2. In Preferences → User Interface Language, change the language to a non-English option (e.g., Japanese or Spanish) or vice versa if you created a wish in Spanish.
3. Wait for MinT translation to load or trigger translation if not automatic.
4. Observe the tags field on the wish page.
5. ❌ AC1: Confirm that all tags are translated into the current UI language and displayed using a clear, consistent separator (e.g., comma, bullet, or pipe), with no concatenation or formatting errors.

Spanish to English did not translate as good as Spanish to French for Tag and Phab Tasks

Spanish Wish	❌Translate to English	✅ Translate to French

Test Case 2: Verify MinT translation and formatting for Phabricator tasks field

1. On the same wish page, locate the Phabricator tasks field.
2. Observe the display of task references (e.g., “T123456”) and any associated text.
3. ❌ AC2: Confirm that the Phabricator tasks field is translated where applicable, formatted consistently, and uses the same separator style as the tags field.

See AC1

Test Case 2: Verify Correct Behavior When UI Direction Matches Wish Language Direction

1. Change your content language to match the wish language direction (e.g., switch UI language to Hebrew).
2. Navigate again to the RTL wish page.
3. Trigger a voting action (Support, Edit comment, or Remove support).
4. Observe the green success message.
5. ❌ AC3: Confirm that in this matching-direction scenario, the close button appears in the correct mirrored position for the language.

🟩See AC2

❌Mobile

❌ Mobile: En-RTL	🟩 Mobile: Hebrew-RTL Submit	🟩 Mobile: Hebrew-RTL Edit	🟩 Mobile: Hebrew-RTL Remove

@MusikAnimal Confirmed that the “Move” link is not visible in the tools menu and when accessing Special:'MovePage'/Community_Wishlist/W26 displays the error message “This page is not movable, as seen in the videos below. I will mark this as Resolved. Thanks for all your work!

@MusikAnimal Confirmed that wish titles on the Community Wishlist display user-entered wikitext literally across all viewing contexts (including wish pages, and the wish-index table), without rendering HTML or wikitext, except for <span> tags containing lang or dir attributes, which should be preserved, per videos below. I will mark this as Resolved. Thanks for all your work!

@SBisson Confirmed that all supported Wikipedia languages appear correctly in both the dashboard and ContentTranslation interface, without any errors, as seen in the videos below. I will mark this as Sign-off. Thanks for all your work!

In T405388#11418100, @Samwilson wrote:

@GMikesell-WMF Hopefully this is all groovy now!

@SBisson Confirmed Page collection 'None': newly fetched error no longer exists, as seen in the screenshot below. I will move this to Sign-Off. Thanks for all your work!

This is not QA testable, and the code prevents duplication. I will move this to Sign-off. Thanks for all your work!

In T345845#11407054, @ngkountas wrote:

@GMikesell-WMF it is my understanding that the lead section is always supposed to be there, and this is the reason why even the parse endpoint doesn't return it in the tocdata response (e.g. https://en.wikipedia.org/w/api.php?action=parse&format=json&formatversion=2&prop=tocdata&page=Moon). So, I believe that the lead section can be empty, but not "missing", and it's never expected to be in the missing sections list.

Handling empty lead sections is something that we could support but I believe that this is a corner case, that we may never need to address. Even if we need to, that can be done as part of some other task.

In T410662#11407649, @MusikAnimal wrote:

In T410662#11407606, @GMikesell-WMF wrote:

@MusikAnimal, very minor, but can you review the AC2 Page History video? It's more of just the highlight at the end of the video.
…

6. ✅❓ AC2: Confirm that the summary does not report “Description updated.”

The status only changed but when comparing it shows status but also one of the tags highlighted for some reason even though it wasn't touched.

❓Page History	✅ Other Places
F70654132	F70654134

Yeah, the form will enforce a specific order of parameters and values. For the purposes of automatic edit summaries, this can be ignored. Such edits do not make any functional or visual changes, so I don't think it's important for it to be mentioned in the edit summary.

@MusikAnimal, very minor, but can you review the AC2 Page History video? It's more of just the highlight at the end of the video.

@ngkountas Please review AC2, thanks!

@SBisson Recommendation API is showing that it's not emptying the cache, as seen in the screenshot. I will move this to Sign-off. Thanks for all your work!