Talk:Page Previews

Page Previews solves the core problem of users opening multiple tabs to gain an understanding of a word in the context of the subject they are reading. Whenever a reader hovers over a link to another article, a short summary of the subject, including its graphical image, is provided to them so they can decide whether they need to visit that subject more fully before continuing the current subject.

Please give us feedback on your experience using this feature so we can change and improve it. Each language is welcome in this discussion!

You can read more about the feature here.

Known Issues

• All issues with potential work attached to them tracked here: https://phabricator.wikimedia.org/project/view/765/

I encountered a weird preview image today that I cannot explain (at least without digging more into it).

On the English Wikipedia, making a link to en:Prithvi shows File:Necrotizing fasciitis left leg debridement.JPEG (warning: not a nice image to look at) in the page preview popup. See en:User:Nclm/sandbox or the infobox on en:Earth.

As far as I can see, the image is not inserted on the destination page or on its Wikidata item.

Any idea what’s triggering this image to appear here (and how to prevent it)? Thanks!

There was vandalism in a local template, but it was reverted (I won't link it for w:WP:BEANS reasons!). Sometimes the cache takes a little while to catch up. The image has also been added to the Bad image list.

It works now.

Visit anonymously (logged-out) ro:Special:Permalink/15340489:

• 1.: If you hover over "Iepure ryukyu ", the popup appears. If you hover over "(P. furnessi)", there is no popup.
• 2.: If you hover over "Iepure ryukyu (P. furnessi)", there is no popup.
• 3 & 4: If you hover over "Iepure ryukyu (P. furnessi)" or "Iepure ryukyu (P. furnessi)", the popup appears. No problem here.

Note: When I went to the link and tried them, some entries did not generate popups. However when I went back over them second time to more carefully examine which did or did not work, they all worked.

Speculation: Either there was an issue with some of them being slow and we just abandoned the hover before it could come through, or hovering a later version somehow fixed the earlier one. A wild speculation, but is it possible that hovering a later link generated a cache-hit which incidentally fixed a link that - in isolation - didn't work?

As of 11 February 2023, the bug still persists.

I'm moving these here, from the project page where I originally listed them. Feel free to edit this to add any you find.

No endorsement of a particular extension is implied.

---

Browser extensions/addons that show mouseover popups within Wikipedia

Chrome

• wikipedia plus
• wikipedia quick hints
• wikipedia smart links
• wikipreview
• wikitweaks
• wiki it
• hoverpedia
• LiveWiki (github)
• wikipedia peek
• wikipeeks for wikipedia
• wikipedia hover
• wikihighlight
• wiki on speed
• wikizoom
• wikipopups
• qwikipedia
• wikitopichover
• easywiki

Firefox

• wikiest
• wikipedia peek

---

Browser extensions/addons that show Wikipedia/Wiktionary content at any external site

Chrome

• wikipedia-lookup-browser
• quick wikipedia lookup
• qikipedia
• wikipedia popup

Firefox

• quickwiki
• wikipedia anywhere
• wikipedia page previews everywhere
• haidoku

---

Full library for embedding in any web page

• github - AnandChowdhary/hovercard (live demo)

Another one for Chrome, launched in August 2016: "LiveWiki" (https://github.com/mrusa/livewiki )

There are similar tools like this Page Previews feature, however that shouldn't stop our community from making ours. Having one official tool providing the best features in a simple way for everyone is a great idea which doesn't need installing browser extensions.

Listing the other extensions and add-ons is useful because we can review their design and features to improve our version.

Yup, that's exactly why I started/researched the list. To show how popular the idea was (proving we ought to implement something) and to glean good ideas/designs from. :-)

Think this means this feature really needs to be globally rolled out to non-registered users then... Maybe leave as an option for registered users though because some prefer third party gadgets like Popups on english that give you way more details (for editors)

To EoRdE6: I agree that this feature would good for everyone outside beta testing (it is a tool made by many others), however this shouldn't happen too soon because it needs to be finished (main problems fixed, features added). Also an option for users to disable it on their account could be a good idea but it would be better to make Page Previews/Hovercards have the popular features of other third party tools so users would use our official tool.

My issue with that is that editors still have very different requirements to readers therefore a reader centric tool will never function for editors... Third party tools allow editors to view page history and editors and block logs and protection and tons more all from the pop-up. It's messy and ugly but for editors it's useful. Readers have no use for that information so I would support giving them this basic version that is currently available...

To EoRdE6: I see your point but we could have these editor only stats in Page Previews/Hovercards as opt-in features enabled on users' settings pages which could get some editors to use our tool instead of competitors' ones to keep ours supported and popular.

There is also a library that can be embedded in web pages, AnandChowdhary/hovercard. (Have not tested.)

Very easy to implement Wikipedia preview box (JS & CSS) for any website, works on desktop & mobile.

Project, examples: su-pa.net/wikiPrevBox/

GitHub: github.com/su-pa/Wikipedia-preview-boxes/

The page preview for a page I'm editing auto selects an image that is not the ideal one for the preview. Is there a way to control which image is selected for the page preview?

Hi. Yup, there are some docs at Extension:PageImages#Can I exclude certain page images? which should help.

Page Previews#Logged Out Users

The problem is that if you delete cookies often you will have to turn it off every time. It is even worse if you don't allow cookies, there is no way to turn it off

Disable javascript.

Yes, that works, but I don't think is a long term solution. right now I'm messing with some filters for adblockers. this 2 seem to do the work:

en.wikipedia.org##.mwe-popups-containeren.wikipedia.org##[role="tooltip"]

1st one hides the pop up, and the other one hides the little arrow. what I don't know is if they affect anything else

this destroys all pages that make responsible use of JS

A fair question. If you use a content blocker in your browser of choice you can always modify your client-side CSS to hide the container for Page previews. Although, doing that will make me sad. :)

I meant to reply here, so I'll copy paste the message. Sorry, it is my first time writting here.

apparently copy paste doesn't work. anyway, the message is just below. can you tell me if those 2 filters are correct to block the page previews?

Could you kindly give me a rule to block it? The problem I have is that it is distracting when you scroll down and don't mean to hover any link, or when you put your mouse over a link by mistake. I don't find it really intrusive or anything, in fact I liked it at first. but after browsing for a while it is just distracting

right now I made a couple of rules for adblock and they seem to work, but I'm not sure if I'm blocking anything else by mistake, can you tell me if they are correct?

en.wikipedia.org##.mwe-popups-container

en.wikipedia.org##[role="tooltip"]

After trying to write some rules to block page previews for a while, it is getting ridiculous. I must be doing something wrong because I can't get rid of the little arrow that pops up, it seems it is a different one for different kinds of links. here is the list of rules so far:

en.wikipedia.org##.mwe-popups-container

en.wikipedia.org##.mwe-popups.mwe-popups-fade-in-up.mwe-popups-image-tri.mwe-popups-is-not-tall

en.wikipedia.org##.mwe-popups.mwe-popups-fade-in-down.flipped_y.mwe-popups-is-not-tall

en.wikipedia.org##.mwe-popups.mwe-popups-fade-in-up.mwe-popups-image-tri.mwe-popups-is-tall

en.wikipedia.org##.mwe-popups.mwe-popups-fade-in-down.flipped_x_y.mwe-popups-is-not-tall

en.wikipedia.org##.mwe-popups.flipped_x.mwe-popups-no-image-tri.mwe-popups-is-not-tall.mwe-popups-fade-out-down

en.wikipedia.org##.mwe-popups.flipped_x.mwe-popups-is-tall.mwe-popups-fade-out-down

en.wikipedia.org##.mwe-popups.mwe-popups-fade-in-up.flipped_x.mwe-popups-is-tall

en.wikipedia.org##.mwe-popups.mwe-popups-fade-in-up.flipped_x.mwe-popups-no-image-tri.mwe-popups-is-not-tall

en.wikipedia.org##.mwe-popups.mwe-popups-fade-in-up.mwe-popups-no-image-tri.mwe-popups-is-not-tall

There has to be any other way, can anyone help me to write a simple rule?

Try the following:

en.wikipedia.org##DIV[class^="mwe-"]

Removes all DIVs with a class starting with "mwe-".

.mwe-popups {

display: none !important;

}

HOW DO I TURN THIS REALLY ANNOYING FEATURE OFF PERMANENTLY????

Every time I empty cache or cookies, I have to turn this STUPID GIMMICK off again.

Wenn du AdBlock verwendest, geht es folgendermaßen:

Filtereinstellungen | Eigene Filter | Filter hinzufügen

In der Zeile "Filterregel" untenstehende Zeile eingeben. Für das deutschsprachige Wikipedia en.wikipedia in de.wikipedia ändern.

en.wikipedia.org##DIV[class^="mwe-"]

Wenn du AdBlock verwendest, geht es folgendermaßen:

Filtereinstellungen | Eigene Filter | Filter hinzufügen

In der Zeile "Filterregel" untenstehende Zeile eingeben. Für das deutschsprachige Wikipedia en.wikipedia in de.wikipedia ändern.

en.wikipedia.org##DIV[class^="mwe-"]

When there is an internal link to Wikipedia that links to the main page, the following Page Preview pops up:

Wikipedia Main Page popup

I'm not sure if this is expected behavior but I feel it could be replaced with something more friendly to a user, like "The Wikipedia main page".

Is it possible to omit leading spaces before an (omitted) parenthesis? At the moment, the space is left in, leading to a format like in Sailor_Moon_(character), where commas have spaces preceding them where the parentheticals were.

Additionally, removal of certain templates results in double commas, as at J._K._Rowling, though this seems like less of an easy fix.

Hi,

I'm not sure where Page Previews pull their content from - I've found one this morning that differs wildly from the article it links. On the 2017 Honduras General Election page (link A, below), under the Supranational bodies header, when you hover over "Organization of American States", the preview text reads:

The Organization of American States, or the OAS or OEA, is a continental organization that serves to control American puppet states in the Americas. Headquartered in the United States capital Washington, D.C., the OAS's members are the 35 independent states of the Americas.

This is not an objective or factual statement, and differs wildly from the article that the OAS link leads to. The word "puppet" appears nowhere in the article source - which was where I went first in my attempt to find and revert the vandalism.

The previews feature is great, but I really hope that it is refined so that vandalism is easier to revert/address in the future.

A: https://en.wikipedia.org/wiki/2017_Honduran_general_election#Supranational_bodies B: https://en.wikipedia.org/wiki/Organization_of_American_States

The article was vandalized 23:21, 1 June 2019. The vandalism was fixed within one minute.

For some reason the vandalized version remained as the active version in the page-preview cache for over 17 hours. I preformed a purge on the affected page which successfully cleared out the vandalism.

I'm not an expert on the caching, but one of the devs might want to look into why a few seconds of vandalism got stuck in the cache for so long. Is it possible the two edits were asynchronously processed in the wrong order? It would be bad if the software didn't spot something like that. A swift revert like this tends to be a significant red flag for blatant vandalism.

P.S. 143.85.163.1 thanks for the report. Any edit to Organization of American States would have fixed it. It can also be fixed by purging the page, adding ?action=purge at the end of the OAS address and loading it. Like this: https://en.wikipedia.org/wiki/Organization_of_American_States?action=purge

This problem still exists. The preview for Angolan Civil War is vandalized, but I cannot find the text anywhere in the article. It's really aggravating.

This is currently a problem on [[wikipedia:Gateway Arch]]. Vandalism was rolled back within a minute, but the irrelevant first image is still showing up in the page preview. I wasn't sure how/where to report this? (sorry, unsure of how to link to a particular page from in here)

Cache purge after null editing the article seems to have solved the problem

Clicking the link or the gadget text will lead to the correct article

I've found something interesting Page Previews. In enwiki, typing [[Bion of Smyrna]] in wikitext will make Page Previews render Wilfred Bion's intro. WhatLinksHere for both pages shows no similar redirects!

Can someone confirm?: w:User:Eduardogobi/sandbox ~~~~

weird.. I made a null edit to the page and that seems to have fixed it...

Indeed, it is now showing the correct text :)

Hello, the feature currently removes the first parenthesis content. So the preview for the English-language Wikipedia article about France doesn't show "(French: République française)", which makes sense.

However, the preview for biographies doesn't show the birth and death years, which makes the preview a bit less practical. Can you do it?

I suggest you to retrieve the years from Wikidata, rather than parse the article's parenthesis.

Thanks!