Note: if the highlighted text includes a space, when editor remove that space, the wikipedia preview should remain.

what about the case for Word Press?

PR ready for review: https://github.com/wikimedia/wikipediapreview-wordpress/pull/90

Note: if the highlighted text includes a space, when editor remove that space, the wikipedia preview should remain.

Agreed. I've added code to make sure there are no untrimmed preview word formats to begin with.

what about the case for Word Press?

Current approach removes the entire format from both words "Word Press"

what about the case for Word Press?

Can you say more about it? is it removing the space between Word and Press? If so, we need to see how does that impacts the meaning of the overall word.

In T342838#9144868, @SGautam_WMF wrote:

what about the case for Word Press?

Can you say more about it? is it removing the space between Word and Press? If so, we need to see how does that impacts the meaning of the overall word.

Text Word Press, user remove the space to WordPress. I think the meaning of this case not always valid, may bring the code complexity here, so better not to do it as @eamedina mentioned.

In T342838#9144986, @hueitan wrote:

In T342838#9144868, @SGautam_WMF wrote:

what about the case for Word Press?

Can you say more about it? is it removing the space between Word and Press? If so, we need to see how does that impacts the meaning of the overall word.

Text Word Press, user remove the space to WordPress. I think the meaning of this case not always valid, may bring the code complexity here, so better not to do it as @eamedina mentioned.

So if a user removes the space in between then we remove the entire preview right?

yes.

@eamedina For AC1, it does what it's supposed to do but would you still want the preview to come up if you deleted some of the letters of the original? Also, let me know what you think of the last 2 .webm
in the possible issue section.

✅AC1: Test by editing a word linked to a Wikipedia preview and verify that the preview disappears. Verify that undo behavior works as expected

✅AC2: Verify the user can manually add a new preview to the edited word.

Possible Issues:❓
Wrong Preview: When you go from Desktop to mobile via dev tools and click on the word "Philadelphia", it always first chooses a different preview of "Bert Bell" but when you click on it a 2nd time, it will be the "Philadelphia" preview

Desktop to Mobile: When you go Desktop to mobile, click on "Philadelphia" so it can be in the mobile format. Switch back to the desktop and click on the "Philadelphia" preview, it stays in mobile format. It will only go back to desktop format if you refresh the page.

Hey @GMikesell-WMF, let's talk more about the Philadelphia case: I suspect it's a set up issue that the plugin you're testing doesn't have the latest from the main branch yet.

Regarding the other possible two issues: usually when switching from mobile to desktop view like that in a browser, it is necessary to refresh the page to obtain the correct view settings, so I think we can scratch them as non-isssues

@eamedina My testing above was done in Prod. The testing below is from Dev. I did not come across any of the issues that I got from Prod, which was the point as seen in the gifs below. I'll move this to Done. Thanks for all your work!

Status: ✅ PASS
Environment: WordPress- Dev
OS: macOS Ventura
Browser: Chrome 116
Device: MBA M2
Emulated Device:: N/A
Test Link:
http://dev-test.local/wp-admin/post.php?post=6&action=edit

✅AC1: Test by editing a word linked to a Wikipedia preview and verify that the preview disappears.

✅AC2: Verify that the user can manually add a new preview to the edited word.

✅AC3: Verify undo behavior works as expected