Talk:Page Previews/2017

The Hovercards beta feature 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 beta 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

• Current blockers to turning this on for anonymous uses by default are captured here: https://phabricator.wikimedia.org/T70860
• All issues with potential work attached to them tracked here: https://phabricator.wikimedia.org/project/view/765/

Tres bonne fonction

Ajouté la par default FaustinM (talk) 07:48, 7 January 2017 (UTC)

You can't see math symbols, only spaces

Take a look in this hover: https://he.wikipedia.org/wiki/%D7%A7%D7%91%D7%95%D7%A6%D7%AA_%D7%94%D7%97%D7%96%D7%A7%D7%94. You should see text with "... A ... A" but we see spaces instead of A. רן כהן (talk) 09:43, 9 January 2017 (UTC)

i belive its better to make it working only if you click right click NoyaRoyYacov (talk) 14:55, 9 January 2017 (UTC)

Неймовірно зручно (In English: Incredibly comfortable)

Напевне, це та сама функція, яку я чекала найдовше. Можливість дозволяє коротко ознайомитися з новим поняттям та продовжити читати основну статтю. Дякую ;) Imagase Wataru (talk) 20:54, 14 January 2017 (UTC)

Hovercard won't disappear

Hi, I love the hovercards feature! Sometimes, though, when I mouse over a hovercard, it pops up, I read it, I move my mouse away, and the card doesn't go away. I can sometimes get rid of it by remousing over that wikilink or another link, but more often than not, the card will momentarily disappear and then reappear. Sometimes I can scroll up or down to get rid of it. My OS is the ChromeOS on a Toshiba Chromebook. Here's the system info: Version 56.0.2924.58 beta (64-bit)

Platform 9000.58.0 (Official Build) beta-channel swanky

Firmware Google_Swanky.5216.238.5)

Let me know if you need anything else to try and recreate the issue. Thanks, Icebob99 Icebob99 (talk) 17:59, 15 January 2017 (UTC)

Thanks @Icebob99 for the note. We have a task to fix this bug and will hopefully have the update available shortly. CKoerner (WMF) (talk) 22:36, 17 January 2017 (UTC)

I have the exact same problem. The only way I've been able to fix it is by reloading completely, though. GuyDoodles (talk) 22:00, 3 February 2017 (UTC)

I also have the same problem, and therefore disabled the feature. I think the cards should be made dismissable by clicking outside it. Yhynerson1 (talk) 09:10, 25 February 2017 (UTC)

Hmm, that shouldn't be the case any more. Just to make sure I understand, when you move your mouse outside of the window the pop-up is not disappearing? CKoerner (WMF) (talk) 15:42, 28 February 2017 (UTC)

Yes. Even when you click outside of the pop-up or mouse over another link. GuyDoodles (talk) 20:27, 13 March 2017 (UTC)

hahahaha Манастирбрдовита (talk) 19:20, 23 March 2017 (UTC)

When will Hovercards leave beta phase?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi! As the title says, when will the Hovercards-feature end its beta phase? I really like it and would be very happy when it gets stable soon! Benediktneumayr (talk) 08:26, 22 January 2017 (UTC)

Hi! Glad to hear you're excited by the feature. We're scheduling the initial rollouts right now, as well as fixing all important bugs. The rough dates for roll-outs live here. OVasileva (WMF) (talk) 14:59, 26 January 2017 (UTC)

I just have to say that Hovercards are wonderful, i love love love them. Bavb (talk) 09:41, 29 January 2017 (UTC)

Thank you for your answers! Benediktneumayr (talk) 13:50, 29 January 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Hovercards don't show the section of a page that the link specifies

There are many articles containing hyperlinks that go to a specific section of a page when clicked because the other content isn't relevant, so users typically read this content first to understand the topic referenced. The Page Previews/Hovercards feature currently only previews the first section introducing the whole article, which some users would like changed so they can read a summary of the specific section that an article references.

Often, there are links that point to a specific section of a page, but the hovercards always preview only the lead section. Is that by design, or is there work going on so that it previews individual sections as well? Gluons12 (talk) 15:46, 22 January 2017 (UTC)

This is by design, but section previews would be an interesting feature. Pinging @OVasileva (WMF) to share your thoughts with the product owner. :) CKoerner (WMF) (talk) 19:24, 23 January 2017 (UTC)

The Page Previews/Hovercards feature was designed to do that - it's meant to show previews of articles, with the main introduction content only. Showing a specific section seems worthwhile though if the link specifies it as a link anchor (using a fragment identifier) because clicking the link would jump to that part of the page. In that case, a summary/introduction to the part would be useful. I think this functionality has been mentioned before but I don't know how much work has been done for it. Edwardj 123 (talk) 19:38, 23 January 2017 (UTC)

Hi - we haven't done any work on this functionality so far, but currently it is in our list of tentative improvements for the feature after initial rollout - you can look over the highlights of the list here. Also - if you have any ideas for other future improvements, we are tracking them in the "Hovercards Pt 2" page in phabricator. OVasileva (WMF) (talk) 15:05, 26 January 2017 (UTC)

I've spotted some other topics discussing the same idea:

• Talk:Page Previews/2016#h-Support_internal_anchors_e.g._title#subheading-2016-06-11T23:30:00.000Z - "Support internal anchors e.g. title#subheading".
• Talk:Page Previews/2015#h-Display_lead_sentence_of_#Section,_rather_than_of_article_intro-2015-06-30T14:46:00.000Z - "Display lead sentence of #Section, rather than of article proper". Edwardj 123 (talk) 13:54, 24 February 2017 (UTC)

I've noticed the following Phabricator pages mentioned in related topics for this problem:

• Talk:Page Previews/2016#h-Support_internal_anchors_e.g._title#subheading-2016-06-11T23:30:00.000Z: This is captured by this ticket: https://phabricator.wikimedia.org/T65792
• Talk:Page Previews/2015#h-Display_lead_sentence_of_#Section,_rather_than_of_article_intro-2015-06-30T14:46:00.000Z: See this: https://phabricator.wikimedia.org/T65792 Edwardj 123 (talk) 16:36, 11 May 2017 (UTC)

This will never truly work 100% nor can it be expected to, for many reasons:

1. Sections are case sensitive - this is even worse than articles, so while Cat and cat links may lead to the same article, as anchors they wouldn't lead to the same section.
2. Sections don't need to be unique -if you have "Einstein#Schools" and "Einstein#Schools", the first may lead to primary schools, and the second may lead to high schools within the same article. Yet they will share the same anchors. Mediawiki may generate them differently for headings, but most editors probably don't know that and probably won't care to update millions of articles just for "page previews", especially when there's currently no way to detect when these "break".
3. Inconsistency - same page link showing different descriptions. One here has to remember that 99% of most readers don't know what anchors are, nor how they work. Hovering over one link and getting something, and hovering over a similar link and getting something else is inconsistent and confusing.
4. Other tools also generate anchors - the math extension generates an anchor that points to its markup, which can also conflict with article anchors, and will surprisingly just have a formula rather than article text. The same applies to tables and many html elements, which would look pretty bad on a small preview.
5. Sections may also contain unbalanced or unclosed html, tables, and crazy translate markup, and may lead to broken previews.
6. Sections are unstable - because of the way wikitext markup works a section can automatically change every time the page is edited, e.g. =={{REVISIONTIMESTAMP}}==

This idea should probably be rejected in the general tool for all wiki users (including millions of readers). If deemed useful, it could be implemented solely as a gadget for editors who may be willing to deal with all these issues. 197.218.91.1 (talk) 16:50, 14 May 2017 (UTC)

Blank hovercard issue

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi @OVasileva (WMF)! The hovercard appears blank if an article does not have an intro. It would be great if the hovercard automatically showed text from the first section if this is the case. Daylen (talk) 19:14, 30 January 2017 (UTC)

Hi @Daylen - thanks for bringing this up. We are addressing this issue, but a bit differently. Since the content of the first section of a page might not present an accurate summary or representation of the page itself, we have put in a special preview type which lets users know that a preview is unavailable - a more-detailed outline of these can be found on the functionality page. OVasileva (WMF) (talk) 20:15, 30 January 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Brackets () in chemical formula breaks it

So Hovercards removes anything between and including () brackets. OK. However, when a chemical formula is presented with brackets, is gets broken into nonsense. Example in case: en:RDX has opening line:

RDX is the organic compound with the formula (O₂NNCH₂)₃.

In Hovercards it shows:

RDX is the organic compound with the formula3.

(A space has gone too btw). Any solution, here or in the article? Adding:

en:4-Phenyl-4-(1-piperidinyl)cyclohexanol has brackets in the titleword, resulting in Hovercards:

4-Phenyl-4-cyclohexanol DePiep (talk) 17:11, 31 January 2017 (UTC)

Probably worth mentioning at T91344 or elsewhere on the TextExtracts workboard.

It's probably also worth looking into if the <chem> markup could work with Hovercards (don't know offhand)—even if it's currently borked, making an exception to render chemical formulas that use the tag would probably be easier than tweaking broad code related to removing parenthetical content.

Personally, I think the responsible thing's to disable the removal of parenthetical content, and certain bits of HTML (in your example the remaining "3" gets unwrapped from its <sub> element), until that can be done reliably—there are too many edge cases like this where meaning is broken by aggressively simplifying the code. {{Nihiltres|talk|edits}} 21:31, 31 January 2017 (UTC)

Hi - thanks @DePiep for pointing this out. Currently the issue is with most HTML. We're tracking it here, but let us know if there's any edge cases that we might be missing. OVasileva (WMF) (talk) 20:44, 1 February 2017 (UTC)

The tracking OVasileva (WMF) mentions covers this well. It already says 'mathematical'. Maybe Unicode has other () brackets with math semantics (i.e., "use U+9xxy, U+9xxz pair to denote math () brackets"). No need to disable the function for this minor issue. imo, close-able. DePiep (talk) 23:13, 11 February 2017 (UTC)

to dobra funkcja (Polish to English translation: "it's a good feature")

kto się zgadza? Multimat12 (talk) 18:16, 5 February 2017 (UTC)

Os cartões flutuantes poderiam mostrar outra coisa além da introdução

Não há nada que dê para mostrar na introdução, sendo que a maioria dos artigos não tem Novato10 (talk) 13:57, 6 February 2017 (UTC)

Você poderia dar um exemplo? CKoerner (WMF) (talk) 14:26, 6 February 2017 (UTC)

Sim, em Wikicionário aparece ... Novato10 (talk) 14:29, 6 February 2017 (UTC)

Disable hover card focus-ability

The hover card does not need to take focus from the mouse cursor: if you want to enter the target, the cursor is *already on the wiki-link*; the only reason to move is if you *dont* want it.

If the cards didn't focus , they wouldn't be obstructive .. you could flick the cursor through the text rapidly, *and* benefit from the previews.

Could you enable this behaviour as an option so we can at least try it out? 86.148.102.241 (talk) 17:41, 7 February 2017 (UTC)

The card does not take the focus. Pressing a cursor key scrolls the window. FriedhelmW (talk) 21:36, 7 February 2017 (UTC)

The rollout plan, and clarification on how the community interprets consensus

There is a rollout plan in progress(?!) but the only community consensus on it was quite opposed to default-on deployment.

Perhaps this was unclear because the close was written as "No Consensus" (to enable) rather than "Consensus against". This is not unusual when the effect is expected to be essentially the same. Often language like "no consensus (for a proposal)" is used to more openly invite a new discussion, if anyone feels it may lead to a different result. (Either because changes have been made, or because circumstances have changed, or because someone wants to bring new information or arguments to the table, or becomes someone simply thinks that views on the subject may have shifted over time.)

The WMF may be able to (cautiously) go forwards with a project in a genuine non-consensus situation, where the results were close and other factors might support it. However in this case the closer cited a fuzzy&incomplete vote ratio of about 3-to-1 against, and the closer noted that factors other than raw vote count don't lean in the support direction. My generous/optimistic interpretation would put the result at about 2-to-1 opposed. This is important, the RFC topic was "Proposal: Enable Hovercards by default" and there was "no consensus" to take that action. However imagine we rewrote the RFC question as "Proposal: Disable Hovercards". Imagine everyone responded the same way they did the first time. That same 2-to-1 result would pretty well constitute a consensus to disable. Therefore the "No consensus to enable" is effectively a "Consensus against enabling". It was just phrased to be more friendly if you want to try raising the topic again. (Or maybe the closer always uses "no consensus" language to summarize any failed proposal.)

I didn't participate in that RFC, but I'd like to offer my experience with Hovercards. It sounds like a great idea, and I actively tried to help the project along. I hate how often the WMF&community get into conflict and I really wanted to help a project succeed. I enabled Hovercards and played with it, and it seemed great and useful. "Neat, I can get a preview whenever I want". Then I stopped playing with it and when back to normal. Over the next few days it became clear that I was never actually using Hovercards. In fact it became increasingly annoying to have unwanted popups randomly blocking my ability to read the current page. The longer I left Hovercards enabled, the more frustrating it became to have my view repeatedly and randomly blocked by popups. Hovercards are a great idea in theory - you get preview when you want it. In practice, for me at least, ~100% of the popups turned out to be unwanted and frustrating.

Hovercards are a love-it or hate-it feature. I know your survey got pretty positive numbers, but I have to wonder if some of that positive feedback was like mine... that Hovercards only seem great on first impression when you're actively playing with it. Even if a majority of people do like Hovercards, even if you try to make them easy to disable, I think too many people will get pissed off. This is especially critical for logged out users. They'll get really pissed off repeatedly trying to shut off Hovercards every week or every month or whatever. If there is another RFC then I'll have to regretfully oppose any enabled-by-default. Alsee (talk) 16:00, 15 February 2017 (UTC)

 

Hey Alsee, when you say community are you referring specifically to the English Wikipedia? I'm assuming so in my response.

Beta Features/Hovercards#Rollout Plan shows there's no check mark for the English Wikipedia. We have not approached that community since the RfC to address the concerns raised. However, a quick look at that RfC I can see that most of the more egregious issues are addressed with our plans.

1. Editors are opt-in. They won't get the feature enabled by default.
2. Non-logged in folks can opt-out. There's a preference they can set without logging in to disable the feature.
3. The big bugs have been addressed (and many smaller ones). Especially Page Previews getting stuck - the most frustrating of all if you take a look at the talk page here :)
4. There were concerns around user experience. The research and feedback received during A/B tests address if folks understand the feature and how to disable/enable.

This also doesn't mention the qualitative and quantitative research the team's done since the English Wikipedia RfC to investigate if Page Previews negatively impact things like page views, performance, and fundraising. Spoiler alert! Nothing strongly negative was discovered. :)

As you described in great detail, the RfC did not obtain consensus. Like we've done for the 4 communities we have already approached, we state our intent for the feature, reference our rational and research, provide the community time to respond with questions and concerns, and then hopefully move forward if there no outstanding issues. The same will apply with the English Wikipedia.

Really, now that I'm looking over the RfC a little more I think the latter part of Jon Katz's descriptions of the next steps in the RfC are pretty much what I've described above!

I hope that alleviates some of your concerns. Thank you for taking the time to investigate and greet us here with the information and feedback you've provided. I appreciate it. CKoerner (WMF) (talk) 17:33, 15 February 2017 (UTC)

Oh, and another thing we haven't mentioned yet. The new refactored version of Page Previews will arrive (as the current opt-in Beta Feature) next Thursday (23 February) if things go to plan. We should have a message out to the wikitech-l maling list tomorrow. Having the updated code in the Beta feature allows communities use the feature and provide feedback as we approach them.

I hope you (and others reading) will give the feature another try when the updated code arrives and provide feedback on performance, bugs, and what not. CKoerner (WMF) (talk) 17:39, 15 February 2017 (UTC)

@CKoerner (WMF) thanx. And yep, I was referring to the (linked) English discussion on it.

Like we've done for the 4 communities we have already approached, we state our intent for the feature, reference our rational and research, provide the community time to respond with questions and concerns, and then hopefully move forward if there no outstanding issues.

Three :) and I see you're going back for #4.

However I'd like to point out a common pattern. Stuff gets pushed out to small wikis because they don't/can't effectively participate. English Wiki shares a common language with the WMF. English is the oldest, largest, most established, and most engaged Wiki. Some of the the other large wikis have a well developed central community and sometimes engage, but it often takes a pretty big issue for them to climb over the language barrier to effectively participate. This is amplified when WMF postings tend to come across as "announcements". On EnWiki there was a "Proposal to enable Hovercards". It was posted as an RFC for a meaningful examination of consensus. I used machine translation to look at the other four wiki postings. You posted the A/B results, you stated that you want to enable Hovercards, you invited feedback, and you announced that you intend to deploy it unless you see serious problems. That got almost no participation. It was not treated as a significant discussion, much less a consensus process. For example on Russian Wiki it looks like two people posted clearly supportive comments, one person explicitly tried to cast an oppose

En:wp:!vote

, and I think another badly-translated response is a second oppose !vote. There was negligible participation (2 vs 2), and no attempt to form any kind of consensus because it was just an announcement. People aren't likely to turn on a beta feature and seriously investigate the issue just to post a throw-away comment after an announcement.

Let's put it this way. Let's say other major wikis do seriously examine Hovercards, with consensus in favor. That would suggest that maybe EnWiki got it wrong for some reason, and consistency across wikis is a reasonable factor to weigh. That would make a strong case for reconsideration of the EnWiki position. Now let's flip it the other way. English is almost half of our global community, and let's say a few other other major wikis agree with the EnWiki consensus. I think that would make a seriously strong case that the WMF shouldn't push a product out to the smaller wikis that can't/don't effectively participate. If wikis representing a majority of the global community consider it a problem then it's safe to conclude that it would be a problem for small wikis too. And again, consistency itself is a factor to weigh. Tiny wikis shouldn't have weird random configuration differences without a really good reason. A lot of people visit more than one wiki. It's undesirable for things to randomly appear or disappear.

It's a bad idea to do these bottom-up deployments, especially when there's a known problem. Micro wikis never reject anything, but that means they never accept anything either. The last thing you want is to deploy something to 200+ micro wikis that never speak up, then reach to the top few wikis and discover that the whole global community sees a problem with it.

I strongly urge RFCs on the other top wikis before the "deploy everywhere" step. Alsee (talk) 22:57, 15 February 2017 (UTC)

@CKoerner (WMF), I'm correcting myself. I mentioned a Russian discussion above, but I now see there were two discussions. The earlier discussion, which I missed, was posted as a question and it did get a meaningful discussion. (It was small by EnWiki standards, but reasonable in proportion to community size.) It looks like it was mostly positive.

I was particularly concerned when it looked like nowhere had really asked for Hovercards. I have no complaints about deployment to Russia. That reduces, but does not eliminate, my concern for the interests of other wikis. It looks like we basically have a small positive result at RuWiki, and a large negative result at EnWiki. Is there anything additional to indicate that silent wikis want it? (I'm trying to objectively evaluate the good-faith expectation, if they actively voiced their interests.) Alsee (talk) 18:14, 17 February 2017 (UTC)

One small correction.

1. Catalan
2. Greek
3. Russian
4. Italian

4, but who's counting. :)

I want to make sure I understand your suggestion. Are you suggesting to start deployments of features with the largest, most active, most vocal communities? Is that correct?

The near default method of deployment for software by the Foundation has been to start with smaller - and smaller interested communities - then build up to the bigger projects. It has many advantages - eager communities are more likely to adopt new things, working with smaller communities and discovering bugs - that don't mess with bigger projects! That sort of thing. With bigger projects - more people, more eyes - the alarm is often louder when things do break! :)

I see what you mean that these larger communities are more active - in articles, edits, page views, etc. I'd be curious to see numbers of percentages between say page views, active contributors and edits to the Project: namespace. That might be one way to amplify your claim, if I understand it correctly, that larger wikis would catch problems quicker/better than smaller projects.

Rereading your comment, this sounds a little like you're advocating for the smaller wiki's because "English Wikipedia knows better". That seems a little dangerous. I don't want to speak for communities I'm not familiar with, but I'm not sure they'd be comfortable - formally or not - with English Wikipedia leading decision making on what features their communities should consider. But then again, maybe they'd like a leg up? Something to consider.

>Tiny wikis shouldn't have weird random configuration differences without a really good reason

Of course. If you have an issue with the methodologies used and don't believe the work of the team was done with good reason, please explain them so we can improve.

It's not called out in our roadmap, but we are sending a notice to the Village Pump of communities in Phase 1. I have a draft of a short version and we're considering reusing the same announcement for the communities we have reached out to as well.

>It's undesirable for things to randomly appear or disappear.

Agreed, which is why we are approaching each community early, to the best of our ability, notifying them in an appropriate (most appropriate?) venue and giving them time to discuss.

>I strongly urge RFCs on the other top wikis before the "deploy everywhere" step.

You are more familiar with the RfC process than I. :) CKoerner (WMF) (talk) 23:29, 15 February 2017 (UTC)

Re-reading my reply I hope I'm not coming across as disparaging. I think the conundrum is that an RFC at the end of the development of a product is not a suitable replacement for early engagement with communities on changes. However, and in all honesty, this makes it sticky to talk about now as we're so far down the path for this feature. That's not to say I'm not enjoying talking about it or that it's not worth it, quite the opposite! I'm also/obviously talking to others in the team as well.

It's late where I'm at. Happy to continue the discussion with you later. CKoerner (WMF) (talk) 05:13, 16 February 2017 (UTC)

I am delighted with your reply. The subject of WMF-community engagement is sometimes awkward.

Early input on a project is definitely critical, especially prior to build phase. It has been challenging to build that early engagement process. Trying to engage a diffuse global community is hard. I fear that arguments for inclusivity have, at times, led to an all-or-nothing trap. The valid goal of inclusivity should not undermine easiest or "reasonable effort" engagement. I hate to single out EnWiki, but it shares the WMF's language and its size and experience make it the easiest and most effective point of engagement. EnWiki alone represents forty-odd percent of the global community. EnWiki plus two other big wikis covers a majority of the community. A top-down approach can get you far, for whatever outreach is manageable.

I'm not sure (small wikis would) be comfortable - formally or not - with English Wikipedia leading decision making on what features their communities should consider.

To clarify, all communities can consider and request anything. A main concern was how silent wikis are handled.

When smaller wikis can't or don't speak up, the rest of the community is their best representative. This is basically how we already manage wikis. There are a vast number of casual editors with no knowledge or interest in community management, and lots of major editors with no interest in doing that work. The most dedicated, most experienced, and most interested community members do the work of community-wide management. Everyone is welcome to show up, and the work is done by those who show up. I think our public-service mission and our culture of consensus makes the core community pretty good at trying to serve those who didn't show up.

I very much want a better voice for other communities. I'm sure smaller wikis feel powerless and voiceless. An announcement that invites an RFC is likely to be far more effective. People volunteer to do work when they know it's meaningful. A concrete question is key. In the pre-build phase it would be great to see something like "Is this something you think you would want". Along with that you can ask for feedback on features etc. That feedback will generally be very fuzzy unless there is a focused discussion on it.

Are you suggesting to start deployments of features with the largest, most active, most vocal communities? Is that correct?

Deployment is complicated and has competing factors. It absolutely does makes sense to start small, to get bugs fixed, to get initial feedback, and make sure things don't explode :) What I am saying is that top wikis evaluate it before global-hundreds-of-wikis deployment. Bottom-up deployments are risky. It's the "path of least resistance", but that path also leads directly to the worst case scenario. The WMF wouldn't built a product unless you believe it is beneficial, so the WMF is sometimes eager to deploy that benefit to silent wikis. Everything seems to be going great, then you get to the last few wikis and suddenly a majority of the global community objects. At that point the options get bad. Trying to "finalize" the project by pushing out the last few deployments can result in a crisis. Rolling back hundreds of deployments is ugly, especially if a rollback itself is somehow disruptive. Partial deployment may or may not be viable, depending on the product. But if the wikis who do speak up are objecting to deployment, the good-faith assumption should be that the silent wikis would also object. That can make the silent deployments look bad.

If a product is expected to be optional per wiki, I'd suggest testing small, then validate whether any engaged wikis actually find it desirable before pushing it to silent wikis.

If a product is expected to be "everywhere", I'd suggest testing small then (maybe) consider jumping to the top. If a universal deployment is going to blow up, EnWiki will give you that answer. Chuckle. It's a tough call. You want the product as bugfixed and improved as possible before getting there, but it's not good for virtually half of the community to be the last ones to say it needs a major change or that there's some fundamental problem. It mostly comes back to effective early engagement to

I see what you mean that these larger communities are more active - in articles, edits, page views, etc. I'd be curious to see numbers of percentages between say page views, active contributors and edits to the Project: namespace. That might be one way to amplify your claim, if I understand it correctly, that larger wikis would catch problems quicker/better than smaller projects.

And it's not merely a question of catching an issue. People need to believe they can do something meaningful to address it. The information needs to bubble up to somewhere useful. For small wikis, the WMF is impossibly far away. They don't feel they can do anything meaningful about the software, they don't have people focusing on it. This will grow, if people see they can contribute valuable work in the area.

Probably the best and simplest thing is to just to look at the community's equivalent of Village Pump. That's where generic wiki-wide issues are handled. That should show the organisational and human resources available for arbitrary engagement. That's where people show up looking to handle generic community work, where you'd find people who would opt-in to a beta feature specifically as community-service work testing it. Alsee (talk) 01:34, 17 February 2017 (UTC)

Phew, it's been a crazy few weeks. I had a moment to pop in and catch up.

>A top-down approach can get you far, for whatever outreach is manageable.

I think this may be the first time anyone has mentioned top-down in the context of Wikimedia. :)

>What I am saying is that top wikis evaluate it before global-hundreds-of-wikis deployment.

I think I understand what you're saying - English Wikipedia can appear to be "low-hanging fruit" when it comes to getting feedback, iterating, etc. However, we're a global movement and while that makes it hard we have to try (as much as we can) to treat each community equally. Showing favoritism, even unintentional, is something we try to avoid.

Fun fact I leaned since we last chatted. Did you know that the foundation use to do deployments on the English Wikipedia first? Apparently other communities didn't like it (and neither did our development teams). It even was mentioned as a process idea a few years back.

I am under the impression that this is exactly what the Beta Features process is for. Do you agree? We can create a way for users to opt-in to early features, test and provide feedback, and then deploy once stable and issues have been addressed. Side note: Page Previews has been a Beta Feature for quite some time. Which over 60,000 editors have enabled (more than the NavPopups gadget!) on English Wikipedia).

>And it's not merely a question of catching an issue. People need to believe they can do something meaningful to address it. The information needs to bubble up to somewhere useful. For small wikis, the WMF is impossibly far away. They don't feel they can do anything meaningful about the software, they don't have people focusing on it. This will grow, if people see they can contribute valuable work in the area.

How so? I can't speak for other WMF staff (or the WMF as a whole!), but in my work I make sure communication - to any community of any size - has a clear actionable point for feedback. A talk page, replying in-thread, pinging me on my talk page - something. Those don't seem "impossibly far away". In fact, looking at the IP addresses and home wikis of the very Talk page we are discussing on shows that folks can find us from all corners of the movement. :)

I don't know much about your editing habits, do you experience this frustration on a small wiki? Relevant discussions would be helpful here, even if I have to use translation software, to get the gist.

Another conundrum, and one that lends credence to your concerns, on smaller wiki's it can be very easy for the Village Pump (if they have one) to be nothing but posts by the WMF. We are one, communities are many. That's still a sticky point we're still thinking on.

I'm trying to help share some understanding on why we do things the way we do, listen to your concerns, and try to come to a shared understanding. I'm not sure if any of this helps, but I'm happy to continue the conversation - when I have time.

Back to the salt mines. :) CKoerner (WMF) (talk) 22:11, 15 March 2017 (UTC)

>>What I am saying is that top wikis evaluate it before global-hundreds-of-wikis deployment.

>I think I understand what you're saying - English Wikipedia can appear to be "low-hanging fruit" when it comes to getting feedback, iterating, etc.

I'm talking about more than just bug reports and iterating. The WMF has good intentions and great developers, but any company would go bankrupt if it tried to build banking software without talking to bankers first. If the WMF builds the wrong thing, it's bad to deploy it to hundreds of silent wikis and then discover the wrong thing was built. Everyone wants it gone or fundamentally redesigned.

Too many products have been running into problems, and too often the WMF side finds it difficult to understand why. Inviting bug reports isn't enough. The community are out there on the front end running the site on a day-to-day basis, we're immersed in the human aspects. Sometimes what we want may seem strange, but there are generally good reasons for it. The best developer team in the world can't build banking software without seriously engaging bankers about the design.

Ideally there should be effective community input before something is built. And independent of that, there needs to be effective community examination before mass-deployment to silent wikis.

The 2017 New Wikitext Editor was designed and built with zero community input. There is 90+% consensus at EnWiki to block deployment. The problem isn't "bugs". The problems are due to design. I don't know if it is fixable, and if it is fixable it would take a serious overhaul. We would be in a bad position if the 2017 New Wikitext Editor were mass-deployed to silent wikis, prior to effective community examination finding it undeployable.

Small wikis can have trouble just getting a routine bug submitted, and even harder time getting effective action on that bug. A micro wiki can't realistically engage on the design of a New Editor, and it can't provide serious evaluation it after it's built. And even if they could, you'd drown under the chaos of 200 languages. Everyone loses if the "equal/inclusive" goal has the effect of blocking or diminishing effective engagement. It shouldn't prevent large wikis from helping to ensure projects succeed.

>I am under the impression that this is exactly what the Beta Features process is for. Do you agree?

Beta Features is a valuable tool, but it definitely does not serve the same function. Imagine you make a Beta Feature that puts dancing kittens on every page. Some people may love it, and you may get bug reports about kittens that freeze up, but it doesn't answer "Should we deploy this as default for everyone".

>in my work I make sure communication - to any community of any size - has a clear actionable point for feedback. A talk page, replying in-thread, pinging me on my talk page - something. Those don't seem "impossibly far away". In fact, looking at the IP addresses and home wikis of the very Talk page we are discussing on shows that folks can find us from all corners of the movement. :) I don't know much about your editing habits, do you experience this frustration on a small wiki?

We experience the "million miles away" effect even on EnWiki. I can only begin to imagine what it's like for small wikis.

EnWiki is lucky that we have well known and active liaisons, but even then it often feels like tossing a message-in-a-bottle into a million mile ocean. Almost no one leaves their home wiki. There are a very few community members, such as myself, who essentially specialize as liaisons in the opposite direction. I've spent years familiarizing myself with mediawiki wiki and meta and phabricator, and tracking what goes on over here. It's so costly that it often leaves me no time to do regular editing and community work.

For example: I don't read Polish, but I happened to Google Translate their Village Pump regarding a WMF-community matter. I happened to stumble across an unrelated unanimous consensus over on Polish wiki, objecting to a bug in the SingleEditTab deployment. (The bug was fixed for EnWiki, but nowhere else.[1]) And how was it being handled? It was just going to disappear into the page-archives... because the WMF is a billion miles away, no one from the WMF caught it, and no one at the wiki could bring it to you.

I had to bring the Polish request to phabricator myself.[2] Small wikis don't have specialists like me, who bring community concerns to Phab/meta/mediawiki and then track what happens with it. It's especially hard when the candidate pool for such specialists is limited to people who know English. And simply bringing it to Phabricator isn't enough. I have spent three weeks tending to this item, and I still can't get a response whether the SingleEditTab bug will be fixed on Polish wiki... and whether it will (hopefully) be fixed everywhere.

The 2017 New Wikitext Editor is another example. In the WMF-universe this project was "publicly posted". However the number of community members who visit WMF wikis is close to zero. And even for the few of us who do venture over here, the information was impossible to find unless we blindly stumbled across it. Two or three of us did find it. We tried to ask for information on the project. No information was available. We had to wait for the initial version to be completed.

Oops. Another product designed and mostly-completed as an internal project with zero community input. No community input on a project to replace our most critical tool. For all practical purposes, it was designed and built on a different planet.

As soon as the prototype was released, several of us desperately tried to tell the team that the design was wrong. We desperately tried to raise the biggest clearest red flags we could. We stated that there were problems, we stated that there would be a community consensus against it, we said that it couldn't be deployed. We tried for months. Eventually the only option left was to abandon the WMF channels and just plain deal with it as a community matter. Six weeks ago an RFC was opened. It has 90+% consensus to block deployment due to these design issues. The WMF still hasn't engaged the issue in any constructive manner. We're living on two different planets.

The WMF generally does well at listening to bug reports. The WMF eagerly wants to hear enhancement requests. But the WMF still has difficulty allowing any input on design phase, or on whether something should even be built in the first place. And once the product is built, the WMF has a hard time seriously considering anything that would require fundamental changes to what was already decided and built. And all of this is from a EnWiki perspective. For smaller wikis, it's just plain hopeless. They're too small to be taken seriously. The battle to be heard is just to hard. They don't have the population to have people focusing on these issues. The language barrier means almost no one can even try. Alsee (talk) 16:47, 17 March 2017 (UTC)

We started talking about the consultation and deployment of Page Previews but got into the old trope of how the WMF does product development work in general. :) I can't speak to the projects you describe as I was not part of their development (nor am I currently) and we're surely taking up more space on this talk page than necessary. Perhaps there's a better venue to continue the discussion? CKoerner (WMF) (talk) 14:37, 21 March 2017 (UTC)

Sorry for wandering so far from the original topic, chuckle. If you had a specific reply to something, you can always jump to my talk page. I'm always interested in anything that could potentially lead to smoother relations between the WMF and community. Alsee (talk) 19:32, 21 March 2017 (UTC)

Hey Alsee, I see your message here, but it's late on a Friday where I'm at. Monday is a holiday, and then I'm traveling to San Francisco for some annual plan...planning the rest of the week. I wanted to let you know I hear ya, I'll think on this, and get back to you when I have a moment. CKoerner (WMF) (talk) 21:13, 17 February 2017 (UTC)

I'll ping the closer, Dank, in case they would like to agree or disagree with my comments regarding their close. My "optimistic 2-to-1 opposed" was based on the initial 7 responses that you didn't include in your tally, as well as assuming that bugfixes or other improvements converted mixed-votes into supports. Alsee (talk) 16:16, 15 February 2017 (UTC)

Alsee, I was following a random link to meta today and found out you pinged me 3 days ago here ... Generally, I only get pings left on en.wp. Reading quickly, it looks like the hovercard feature will not be enabled by default for registered en.wp users, which (for them) is in line with those RfC results. For unregistered users ... I'm not sure what I think, let me ask around. As soon as I have something, I'll ping you on en.wp.

Dan Dank (talk) 04:44, 18 February 2017 (UTC)

Thank you for making this post here first. From my point of view you should create another discussion (the other one is almost a year old now) and there pay attention to two things:

• Make sure that those who use or have used the hovercards feature participate. For this e.g. make a post about the discussion here or show a banner somewhere to all users who make use of this feature.
• What arguments are made in opposition to the default-rollout? Address these issues by either changes to the software or at least a reply.

Once the 2nd discussion is closed examine what the main issues are, how significant they are and what could be done about them and how many oppose the rollout due to these issues.

If there's for whatever reason rough consensus against or no rough consensus for a potential way of conduct would be enabling it by default for just a group of Wikipedia readers and getting feedback from them. Then, with this feedback-data, create another discussion. Fixuture (talk) 15:20, 26 February 2017 (UTC)

Enable Previews link on every wikipage?

I understand that you want the options to be easily available, but should we really start piling various preference options direction onto every page?

During Hovercards discussions, several people suggested it might be a good idea to upgrade the preferences system. The preference system could potentially be higher profile, and it could be re-worked to be more friendly to readers. Perhaps the initial preference page would focus on items intended for readers.

How about keeping "Enable Previews" within preferences, with the preferences system itself considered for future examination? Alsee (talk) 23:13, 17 February 2017 (UTC)

@Alsee - currently this is only the beta feature behavior. For the behavior upon graduation - previews will be off by default for logged-in users (except for the users currently opted into the beta feature). Users may turn the feature on from their preferences page. Check out the settings portion of the functionality page for more details.

In terms of logged out users, we will be looking into logged-out preferences for the future. OVasileva (WMF) (talk) 11:33, 1 March 2017 (UTC)

Ah, it hadn't crossed my mind that the preferences link doesn't exist for logged out users. That does make it a bit of a mess. Alsee (talk) 16:14, 1 March 2017 (UTC)

Hello Hovercards - bye bye 'last edited'

I see Hovercards has now been rolled out in a new form today.

What a terrible shame to have lost the "Edited x hours/days ago" feature.

Combined with the preview, this piece of quick-see information was so useful. It let me quickly check all the links on one page whilst also gauging how actively edited each destination page was. (A stale page usually merited a visit and could often be quickly enhanced, whereas previously I'd just not be aware of this, and would never have visited the page to check).

I can imagine that non-editors would not find this feature at all useful - but will there be a way to opt back in to this really helpful function of the Hovercard opt-in? Nick Moyes (talk) 23:48, 23 February 2017 (UTC)

This fucking sucks. I really hope it's brought back. It was so useful. It's almost useless for editors now. TBMNY (talk) 06:16, 24 February 2017 (UTC)

There's another discussion of this last edited feature in the topic "What metadata should be displayed (article quality, last edited, user views, settings icon etc.)?" at https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2016#h-What_metadata_should_be_displayed_%28article_quality%2C_last_edited%2C_user_views%2C_set-2016-11-29T06%3A12%3A00.000Z. Related discussions are better linked together. Edwardj 123 (talk) 13:40, 24 February 2017 (UTC)

It would be great to get back "last edited" info. I usually dislike intentional obsoletion. RIT RAJARSHI (talk) 16:11, 25 April 2017 (UTC)

Standard Hovercard

Lately I've been getting 2 hovercards. One, this beta version and the other seems to be a standard feature generally on Wikipedia nowadays. I disabled this version and must say I prefer the standard version as you can see differences between revisions, choose on the card whether to watch or unwatch an article and still get a short description of articles content. Needless to say, for now I'll stick with this one. Also, I found the shadow surrounding the beta version to be a bit distracting. This message is merely to convey my personal observation and in no way am I criticizing the beta version as I've always found it very useful! ~~~~ Robvanvee (talk) 10:29, 26 February 2017 (UTC)

Robvanve, thanks for the note. A quick question if you have a moment. Do you by chance have the NavPopups gadget enabled? I'm not sure I understand what other Hovercards you might be seeing! :) The team did just significantly update the code, but I don't think you'd be seeing both the old and the new! Any feedback would be appreciated. CKoerner (WMF) (talk) 15:46, 28 February 2017 (UTC)

He means he hovers a link and gets BOTH technologies to present a popup. Until recently, when navigation popups was enabled, hover cards would be suppressed somehow. It seems that this logic has recently broken, or was removed or something. —TheDJ (Not WMF) (talk • contribs) 09:28, 3 March 2017 (UTC)

Oh, that's not suppose to happen. :) @TheDJ are you experiencing this as well?

Pinging @OVasileva (WMF) who might know more. CKoerner (WMF) (talk) 17:23, 3 March 2017 (UTC)

Yes, I see the same problem on english wikipedia. —TheDJ (Not WMF) (talk • contribs) 12:23, 4 March 2017 (UTC)

I tested it as well - it seems to be a bug within the new code. The production version was tested and not exhibiting this behavior. For the beta version, I've opened a bug detailing the behavior of both navigational popups and page previews appearing. OVasileva (WMF) (talk) 15:24, 9 March 2017 (UTC)

Hovercards vs Navigation-Popups

Hi, I have been using the Navigation popups for a while. They seem to do similar things, but I prefer the way the nav popups look. Having the Hovercards turn on in addition is problematic because then most of the surrounding text ends up covered. Will Hovercards and Nav Popups be integrated? I hope Nav Popups will not just be discontinued... ~ Tenbergen (talk) 16:02, 26 February 2017 (UTC)

Hi@Tenbergen - no worries, there are no plans on integrating hovercards and nav popups. Once hovercards are graduated out of beta, the feature will be off by default for all logged-in users who are not current users of the beta hovercards feature. To avoid duplicate popups, if you're a nav popups user and you would like to try out hovercards, you would have to disable nav popups first and vice versa. OVasileva (WMF) (talk) 11:27, 1 March 2017 (UTC)

sizce öğretmenlik kolaymı yoksa zor mu ?

bence kolay yönleride var zor yönleride Sengulalp (talk) 18:02, 26 February 2017 (UTC)

Strange character insertion

When hovering over a link to en/wiki/Kiev (in /en/wiki/Hyman_Kaplan), "The population in July 2015 was 7006288797400000000♠2,887,974, making Kiev the 7th most populous city in Europe." appears, where there is "The population in July 2015 was 2,887,974 (though higher estimated numbers have been cited in the press), making Kiev the 7th most populous city in Europe." in the article.

I might have a few guesses as to the reason of the bug, but it does seem to be a problem on the hovercard's side. VanishedUser573228 (talk) 22:16, 1 March 2017 (UTC)

Huh, that's not expected. I've created a task and related it to a larger "Epic" task to get some attention on the problem. The larger task attempts to capture additional unwanted results from text extractions. CKoerner (WMF) (talk) 22:46, 1 March 2017 (UTC)

Well, it's sort of expected, in that it is what was actually there, due to incorrect usage of the nts template. —TheDJ (Not WMF) (talk • contribs) 14:12, 2 March 2017 (UTC)

A very similar problem happens on List of oldest living people when hovering over Emma Morano, as well as the second and third people in the list.

I see "... at the age of 7009370018800000000♠117 years, 92 days, ..." Apparently somehow due to the use of Template:Age in years and days. David Edgar (talk) 15:24, 5 March 2017 (UTC)

FW: Quick Page Previews (Hovercards) update

Hello talk page watchers. I just wanted to share a recent update from Olga, the product manager on the Reading web team, on the status of Page Previews.

https://lists.wikimedia.org/pipermail/wikitech-l/2017-March/087699.html CKoerner (WMF) (talk) 22:14, 2 March 2017 (UTC)

Gut

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Funktioniert gut und ist pracktisch Berlin5 (talk) 15:09, 9 March 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Project registration

How to join you online is the problem that I am facing right now.If you can tell me what to do to start this work, will be happy. Hamad olatunde (talk) 17:02, 9 March 2017 (UTC)

Minor bug: horizontal gradient also affects the forelast row

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

e.g. see the hovercard for W:Collective intelligence: the "g" of "sociobiology" is affected by the gradient as well. Maybe it can be set on the last word only. Alternatively the max-height or alike could be changed. Fixuture (talk) 22:48, 12 March 2017 (UTC)

Now tracked in Phabricator.

For details see my topic "Horizontal gradient – HTML5, CSS and JavaScript code/formatting issues", starting with the comment at https://www.mediawiki.org/w/index.php?title=Talk%3APage%20Previews/2016#c-Edwardj_123-2017-04-21T16%3A52%3A00.000Z-Edwardj_123-2016-12-10T10%3A54%3A00.000Z. Edwardj 123 (talk) 21:40, 22 May 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Praise and Suggestion

I have been using hovercards for a short time, now. I have to say two things:

1. I love them! Don't get rid of them! Keep them forever. They save ALOT of time.
2. Allow them to be adjustable -- Sometimes I get a hover over and if I just saw two more words, I would have enough information to not need to click through. Tmbirkhead (talk) 05:51, 13 March 2017 (UTC)

That's an interesting idea. A user-configurable setting to determine the length of the preview text. It also goes along with a few suggestions folks have had to have an option to not show an image in the preview. I'll bring it up with the product manager and created a task to track requested customization options. CKoerner (WMF) (talk) 14:40, 21 March 2017 (UTC)

The hovercards are a fantastic new feature! However, I do agree with Tmbirkhead, you should be able to scroll down on the cards at least to the end of the introduction section. Sirpalmtree (talk) 19:58, 30 March 2017 (UTC)

very good idea! 2001:7C0:2041:1AA:0:0:0:DB (talk) 06:36, 18 April 2017 (UTC)

Pls add info on non-free images not showing

Sorry all I can do right now is suggest this, but some or all of the points made here by User:OVasileva (WMF) should be included in the discussion of images. Thanks! Geekdiva (talk) 10:13, 15 March 2017 (UTC)

Hovercards should include bold into second (and more) subjects

Hello. In some articles, not only one subjects, but other subjects are exists, according to the orthography issues, or existence of nick(handle)names. but another subjects are eliminated in bold expression of the Hovercard extension. It could make the impression the only first subjects are official, and others are not. I have to this effect should changed into the way which admit the possiibility of diversity of the name of the article. Ellif (talk) 11:38, 15 March 2017 (UTC)

Can you give an example of this problem? Whatamidoing (WMF) (talk) 17:23, 18 March 2017 (UTC)

yes Fikkova (talk) 16:58, 22 March 2017 (UTC)

@Galadrien: good point! The development team is already working on changing the system so that the bolding in the popups appears as it does in the article (which means that any alternative names that are bolded and not in parentheses will appear bolded in the popup).

I don't know when that will be done, but it's part of task T152414. Neil Shah-Quinn (WMF) (talk) 17:23, 27 March 2017 (UTC)

Add the feature to hide "（）" as "()"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It seems "()" and the sentence inside it are hiding on Hovercards, but some languages in Asia use "（）" as brackets, so let's support it to make Hovercards more useful in these languages. Fitonay (talk) 18:29, 18 March 2017 (UTC)

@Fitonay, could you please post a link to a Chinese Wikipedia page that isn't displaying usefully, as an example? Whatamidoing (WMF) (talk) 18:51, 18 March 2017 (UTC)

Chinese:[3]

Japanese:[4]

Cantonese:[5]

Wu language:[6]

Gan language:[7] Fitonay (talk) 19:41, 18 March 2017 (UTC)

For the first article, I went to https://zh.wikipedia.org/wiki/中華民國#.E7.B6.93.E6.BF.9F and hovered over the link to that article in the caption. I see this text:

台北101（TAIPEI 101）是位於中華民國臺北市信義區的摩天大樓，樓高509.2米（1,671英尺），地上樓層共有101層、另有地下5層，總樓地板面積37萬4千平方公尺，由李祖原聯合建築師事務所設計、KTRT團隊与韩国三星物产（Samsung C&T）承造,

Do you see something else? Do you want to see something else? Whatamidoing (WMF) (talk) 01:11, 19 March 2017 (UTC)

I mean Hovercards seem to hide the brackets. For example, first paragraph of Amis language article is:

Amis is the Formosan language of the Amis (or Ami), an indigenous tribal people living along the east coast of Taiwan (see Taiwanese aborigines). Currently the largest of the Formosan languages, it is spoken from Hualien in the north to Taitung in the south, with another population near the southern end of the island, though the northern varieties are considered to be separate languages.

But on the Hovercards, it shows:

Amis is the Formosan language of the Amis, an indigenous tribal people living along the east coast of Taiwan. Currently the largest of the Formosan languages, it is spoken from Hualien in the north to Taitung in the south, with another population near the...

So the Hovercards of 台北101 could be:

台北101是位於中華民國臺北市信義區的摩天大樓，樓高509.2公尺，地上樓層共有101層、另有地下5層，總樓地板面積37萬4千平方公尺，由李祖原聯合建築師事務所設計、KTRT團隊與韓國三星物產承造，於1999年動工，2004年12月31日完工啟用；最初...

Fitonay (talk) 10:53, 19 March 2017 (UTC)

I did not get " 台北101是位於中華民國臺北市信義區的摩天大樓，" in the Hovercards of 台北101. I actually got " 台北101（TAIPEI 101）是位於中華民國臺北市信義區的摩天大樓，" in the page preview.

The Page Preview looked like this:

Do you see the "（TAIPEI 101）" part in the first line, when you go to the same article and hover to get the preview for this article? Or is that missing for you? Whatamidoing (WMF) (talk) 20:01, 20 March 2017 (UTC)

Yes. But it doesn't show in most of other language and I think that is one of the Hovercards feature!

(Did you see the different between Amis article and Amis Hovercards?) Fitonay (talk) 20:12, 20 March 2017 (UTC)

At the English Wikipedia, when I get the card for Amis, I don't see the text in parentheses. I wonder why that is? Whatamidoing (WMF) (talk) 21:47, 21 March 2017 (UTC)

@Fitonay is correct: the removing of text in parentheses is an intentional feature meant to make the preview text more useful (by removing things like alternate names, pronunciations, unit conversions, and so on). This happens on English, but, as they point out, not on Chinese and other East Asian languages because the parentheses characters are different.

Seems like a very useful report—it should be very easy for the development team to fix :) Neil Shah-Quinn (WMF) (talk) 17:18, 27 March 2017 (UTC)

Maybe it is the way to show up more information with priority for the reader at the start. The original text, pronunciation, synonym and conversion may not be the most important information in the page preview. So hide the text in parentheses can spare Hovercards space for other information. Fitonay (talk) 02:10, 22 March 2017 (UTC)

@Fitonay: I have created a Phabricator task so that the developers know to fix this. Thanks for the report! Neil Shah-Quinn (WMF) (talk) 17:27, 27 March 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Delay them more, or require a hover or click to expand a one-line tooltip

I think they are very useful, but so far, they have more often "gotten in the way" then "been useful" for me. Sometimes my cursor just happens to be accidently hovering over a link a little too long while I'm reading another part of the article, and then it literally gets in the way. After all, many articles have a lot of links on them; you can then easily "accidently hover" while reading.

This could be solved either by raising the delay (you'll be happy to wait one full second to get more info, no? while that would reduce 'false positives'), or by changing the 'tooltips' so that they actually start as a oneliner, and they only expand once you mouse over the tooltip, or even click on it. Sygmoral (talk) 22:03, 18 March 2017 (UTC)

Hitting errors on Wikidata

Using Hovercards on Wikidata, hovering over any item link says "Looks like there isn't a preview for this page". If I open the Console, I see the following error:

Exception in module-execute in module ext.gadget.PopupsFix:
/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:176 TypeError: Cannot read property 'match' of null TypeError: Cannot read property 'match' of null
    at eval (eval at <anonymous> (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:1), <anonymous>:1013:1430)
    at eval (eval at <anonymous> (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:1), <anonymous>:1017:666)
    at Object.<anonymous> (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:161)
    at fire (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:45)
    at Object.add [as done] (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:45)
    at Object.always (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:46)
    at runScript (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:161)
    at checkCssHandles (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:161)
    at execute (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:162)
    at Object.implement (/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=0dwr6rr:168)

Numbermaniac (talk) 06:47, 19 March 2017 (UTC)

It looks like this might be the related task tracking work on getting Page Previews to work on Wikidata.

https://phabricator.wikimedia.org/T69434 CKoerner (WMF) (talk) 14:27, 21 March 2017 (UTC)

Anything planned for articles that don't exist yet?

I'm looking at https://phabricator.wikimedia.org/T160831 that my colleague kindly filed, and I wonder if there's anything for the future of PP there. Thanks. Elitre (WMF) (talk) 19:38, 20 March 2017 (UTC)

Pinging @OVasileva (WMF) to see if she has some thoughts on this. CKoerner (WMF) (talk) 13:52, 21 March 2017 (UTC)

make the hoverzoom boxes show more

need more info! less file descrptiony stuff too. Rhodechill (talk) 08:02, 28 March 2017 (UTC)

Welcome, Rhodechill.

I'm a bit confused about the "file description stuff". Are you talking about Hovercards (a sentence or two when you hover on a blue link to another article) or maybe Media Viewer (full-size pictures when you click on an image)? Whatamidoing (WMF) (talk) 21:20, 29 March 2017 (UTC)

when u hover over a hyperlink and a preview comes up, usually has like 2-4 sentences and a thumbnail maybe iirc Rhodechill (talk) 04:12, 9 April 2017 (UTC)

I assume that you want to see more sentences. But I don't know what you want to see less of ("less file descrptiony stuff too" from your first comment). Perhaps that is a less important point? Whatamidoing (WMF) (talk) 05:06, 11 April 2017 (UTC)

hey! now i can see a hoverzoom box from another hoverzoom box awesome!

as for despcitoony stuff:

like this, i went to a random article, the zoom box says:

" 

actions

9.7kB, 106 wikiLinks, 5 images, 2 categories, 25 weeks old

----Qakh District ( ; – K′axis raioni),"

lik the pronunciation and the date there is a bit much, its actually more than 50% of the info provided, and thats just attempt #1 from a random page

is my sugestions even useful at all idk Rhodechill (talk) 08:28, 13 April 2017 (UTC)

Right. Look at this:

There are two different previews showing. Now go to w:en:Template:Administrative_divisions_of_Azerbaijan and hover over the entry for "Qakh". Which preview are you seeing – the one with the big picture, or the one with the menus and the line about file size and age? Whatamidoing (WMF) (talk) 17:01, 13 April 2017 (UTC)

the lower one in your image. however mine has a tiny thumbnail, too.

for most other links, i see both.

is my contribution useful Rhodechill (talk) 07:51, 14 April 2017 (UTC)

Thanks, that's very useful information. You're not using Hovercards. You're using w:en:WP:NAVPOPS. NAVPOPS is a very popular browsing gadget at the English Wikipedia (and some other wikis). Whatamidoing (WMF) (talk) 16:20, 14 April 2017 (UTC)

Is my suggestion going to be implemented?

How did I get navpops and not hovercards? do I have both? how do i get cards? Rhodechill (talk) 04:49, 16 April 2017 (UTC)

You get NAVPOPS by going to the Gadgets tab of your preferences and ticking the box to enable it.

NAVPOPS is maintained by a volunteer. If you want the appearance to be different, then you should first read https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups#Changing_the_appearance_of_your_popups and, if the change that you want to make isn't possible there, then you should leave a message on the talk page there. Whatamidoing (WMF) (talk) 06:00, 19 April 2017 (UTC)

how do i get hover cards then? Rhodechill (talk) 07:54, 25 April 2017 (UTC)

Go to https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures (for the English Wikipedia), and choose the second item, "Page previews". Whatamidoing (WMF) (talk) 21:15, 27 April 2017 (UTC)

I already had both hovercards and navpops. why did you say i wasnt using hovercards?

also, is that talk page ordered in reverse chronological order or is it just me? the one u linked to april 19 Rhodechill (talk) 04:18, 28 April 2017 (UTC)

Are you seeing two cards/boxes for every link? Or just one? Whatamidoing (WMF) (talk) 17:57, 28 April 2017 (UTC)

is that talk page ordered in reverse chronological order or is it just me? the one u linked to april 19

And I was seeing two boxes. I am pretty sure it was hovercards and page previews or whatever the other one was. You seemed to imply I didn't have hovercards which confused me hence me asking ''how do I get hover cards then?

''. I don't think I did have hovercards tho? Then how did I have two boxes? Glitch? Hmm, maybe I did have hovercards when I thought I didn't have them... idk. What do you think about all of this??? Rhodechill (talk) 02:35, 18 May 2017 (UTC)

lol Edwardj

Yes I like to avoid spelling mistakes. Rhodechill (talk) 03:37, 20 May 2017 (UTC)

Why don't you send me a screenshot of what you're seeing? Whatamidoing (WMF) (talk) 19:09, 29 May 2017 (UTC)

Edwardj you missed some like "u" vs "you"

anyway im not seeing it anymore. can't you tell based on what i described? what do you think would be contained in my screenshot anyway, what kind of possuible error? im completely lost and me memory is fucked now. i was just getting two popups at once. one navpop and one hovercard or whatever. its just not happenign an anymore. i feel bad now... Rhodechill (talk) 01:34, 6 June 2017 (UTC)

Hi Rhodechill (talk) 02:59, 9 June 2017 (UTC)

Why throw this discussion out? Rhodechill (talk) 07:36, 13 June 2017 (UTC)

test

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

dbdfdf Rhodechill (talk) 08:03, 28 March 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Picture Preview

I like the hovercards, but why do the preview pictures only show up in some of the link's previews? For example, there is a picture on the hovercard for a link to the McLaren 720S[8] article, but not for the article about Buick[9]. I would like to see the picture every time , so I can have a better idea of the subject. (except for those few articles that don't have pictures, of course) Sirpalmtree (talk) 20:22, 30 March 2017 (UTC)

Howdy. Great question. This is due to a decision to not pull images from further down the page than the lead section. It ended up that many images used that were not in the infobox or introduction were confusing to see paired with the subject matter.

For instance on the Buick article, the image regarding "Valve-In-Head engine" would have been the image used for Page Previews prior to this change (the Buick logo is a non-free image). While related to the subject, as the article is structured today it wouldn't have been nearly intuitive as say a photo of an actual Buick. :)

A little more technical information can be found here: https://phabricator.wikimedia.org/T87336 CKoerner (WMF) (talk) 20:54, 30 March 2017 (UTC)

Non-free images were a problem for the Related Pages feature. Later I opened a community discussion which accepted non-free images in Page Previews. That resulted in T131105 for Page Images to support any-image or free-only, and T147317 to enable non-free images in Page Previews. Both are marked as Resolved.

Something is wrong if Page Previews isn't showing non-free images.

I'm not certain, but I think I recall something about avoiding images with an extreme aspect ratio. Maybe this image is being skipped because it is very short & wide? Alsee (talk) 09:36, 31 March 2017 (UTC)

@Alsee's assessment is probably correct. The aspect ratio of the logo (the only image above the fold), is not of a dimension that makes it eligible to represent the the page. —TheDJ (Not WMF) (talk • contribs) 09:39, 21 April 2017 (UTC)

Ah! You're both right. I misunderstood the question. CKoerner (WMF) (talk) 14:45, 21 April 2017 (UTC)

Invalid image

In category https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%90%D0%BD%D0%B8%D0%BC%D0%B5_1999_%D0%B3%D0%BE%D0%B4%D0%B0 for "Excel Saga" shows a blurred icon <image x="0" y="-11.5" width="300" height="223" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://upload.wikimedia.org/wikipedia/ru/1/12/300px-cel_Saga.JPG"></image> instead of infobox image https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:Excel_Saga.JPG. Sunpriat 21:49, 1 April 2017 (UTC)

Bad text insertion

On https://en.wikipedia.org/wiki/List_of_oldest_living_people , when I hover over the "Nabi Tajima" link (third in the table) I see "...who is, at the age of 7009368124480000000♠116 years, 238 days..." which is incorrect.

I commented a month ago on a very similar thing happening with the "Emma Morano" link on the same page... it's now fixed, but I'm not sure how, so I've no idea whether it's possible to fix this other one myself. David Edgar (talk) 00:03, 3 April 2017 (UTC)

This has been fixed recently. Text Extracts now ignore this type of information. It originates from Age in days and years, and that template needs fixing the core problem, but at least it will not bother any user of Page previews/Hovercards/Popups for now. —TheDJ (Not WMF) (talk • contribs) 09:22, 21 April 2017 (UTC)

Wiktionary support

This feature is unusable on wiktionaries, where the page structure is

== Language name ==
...
...
=== Lexeme type ===
...
==== some other label in some languages ====
# sense of word

Actually, hovercards display only

...

Ideally, they should display something like

Language name : sense of word

Langage name2: sense of word JAn Dudík (talk) 12:02, 5 April 2017 (UTC)

THANK YOU VERY MUCH هيلي شاه (talk) 15:34, 11 April 2017 (UTC)

Hi!

I already mention a lack of Wiktionary support here: Talk:Page Previews/2016#h-Wiktionary_2-2016-11-22T20:42:00.000Z

I really like to have a display of the picture, to see if I may add one, but it doesn't work neither, as it use to with the previous version. Noé (talk) 08:33, 19 April 2017 (UTC)

Tried hovercards, turned them off

I found them more distracting than informative, particularly when looking at articles that include a lot of wikilinks. I started having to care about exactly where my mouse cursor was pointing, when I was merely reading. And in a page with a lot of links, it may not be easy to find some non-wikilinked area to put the mouse into, so that I can just read the ()$*($)@# page in front of me. 2607:F3A0:17:0:219:BBFF:FE4D:28A1 (talk) 00:48, 9 April 2017 (UTC)

"last edited - X minutes ago" feature

The hovercards used to have a "last edited - X minutes ago" feature.

I haven't seen it in a while. It was quite helpful to me.

Why was it removed? Musketeiro8 (talk) 22:40, 13 April 2017 (UTC)

I don't know why that was removed (I'm not involved in that team). However, if that feature is important to you, then you may want to turn off Hovercards and enable the more complicated/feature-filled NAVPOPS browsing gadget instead.

Here's a simple comparison of the two:

The "Hovercard" is the top one, with the big picture. NAVPOPS is the lower one (and sometimes contains small picture, although not in this particular screenshot). Whatamidoing (WMF) (talk) 16:25, 14 April 2017 (UTC)

Hi,

Thanks!

I still prefer the hovercard that showed the date but this is useful too.

Many thanks! Musketeiro8 (talk) 20:05, 14 April 2017 (UTC)

There's another related topic that discusses whether this feature and others should be enabled in the Page Previews/Hovercards tool, called "What metadata should be displayed (article quality, last edited, user views, settings icon etc.)?". See https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2016#h-What_metadata_should_be_displayed_%28article_quality%2C_last_edited%2C_user_views%2C_set-2016-11-29T06%3A12%3A00.000Z. Edwardj 123 (talk) 12:55, 19 April 2017 (UTC)

Hovercards don't work at Wikidata

It shows "Предварительный просмотр недоступен" (Translation: Preview not available) for all items and properties. Earlier it was working though. Infovarius (talk) 19:31, 18 April 2017 (UTC)

Watchlist

Hi,

I notice that the feature also works on my watchlist. It is a little bit annoying because I move my cursor a lot on my watchlist to check several edits, so many hovercards appear for nothing. Moreover, as far as I'm concerned it is not useful on watchlists because I already know all articles I watch...

I don't know if many people asked for Hovercards in watchlists, but for me this is not useful, and even annoying on the long-term.

Thanks for this useful feature on articles anyway ! Regards, Floflo (talk) 09:09, 20 April 2017 (UTC)

@Floflo thanks for the feedback. I created a task in our bug/feature tracking software for the product team to look at. https://phabricator.wikimedia.org/T163453

If others reading could chime in with their own experiences, it would help the team and be greatly appreciated. CKoerner (WMF) (talk) 15:39, 20 April 2017 (UTC)

Many thanks =) Floflo (talk) 16:42, 20 April 2017 (UTC)

We've never seen many complains about it for the Navigation popups, but we do have a slightly longer popup delay there, and the mouse position also has to be fixed/stable during that period. This makes accidental triggering less likely.

I'm not sure how Hovercards/PagePreview/Popups deals with that atm. —TheDJ (Not WMF) (talk • contribs) 09:17, 21 April 2017 (UTC)

Oh and navigation popups has a menu element which allows you to temporarily disable popups for that page, which can be handy in this situation. —TheDJ (Not WMF) (talk • contribs) 09:21, 21 April 2017 (UTC)

Ok TheDJ and thanks. Well, we may drop this topic if I'm the only person to be annoyed, but as I didn't know, I prefered report this and see.

Thanks too, Floflo (talk) 10:28, 21 April 2017 (UTC)

I personally don't mind the Hovercards in the Watchlist, but I could see how it would be annoying. I recommend either increasing the delay, or adding an option to disable the Hovercards. Sario528 (talk) 12:34, 27 April 2017 (UTC)

Hovercard covers link

Hi,

Pretty often when I go to click a link, the hovercard gets in the way. I'm sure there must be some way to make sure the card appears entirely above the link, rather than exactly at the mouse position where this is likely to happen.

Otherwise, a fantastic feature! :) FlyingChrysalis (talk) 10:39, 24 April 2017 (UTC)

Can you describe what you mean with "in the way" ? Does it obscure the line to the point where you cannot read it ? Does it block your ability to click it ? —TheDJ (Not WMF) (talk • contribs) 15:12, 24 April 2017 (UTC)

Sure - the latter. Sometimes it takes a couple of attempts to move the mouse to an area of the link where I can click without the pop-up getting in the way - it chases you.

Using Chrome 58. FlyingChrysalis (talk) 15:42, 24 April 2017 (UTC)

Nice report. Not only links; sometimes it covers important lines/phrases/terms. One way would be great if user can drag and the hovercard from the associated link, up to a limited distance. Another way could be the page auto-detect surrounding links and accordingly show the hovercard at best-side from the link. Even both feature would be able to work at the same time. Thanks ~ RIT RAJARSHI (talk) 15:52, 25 April 2017 (UTC)

Auto-detecting links seems too overkill. It could lead to a whole lot of edge cases making it too complex. Further allowing users to drag the preview seems to be against the fact that it's an hover card. Kaartic ^[talk] 11:35, 27 April 2017 (UTC)

Also some other improvements could be done... such as transparency of the marginal portion should be increased, and corners should be made a bit chamfered; that would free more space. RIT RAJARSHI (talk) 16:04, 25 April 2017 (UTC)

How it would be, if hovercards made available for non-logged-in conditions?

Hi all. The hovercard aka page previews option (still a beta feature) is a great feature. It helps the user read/work, think and find stuffs faster, without losing any focus and flow. How it would be if it is made available for users not-logged-in? RIT RAJARSHI (talk) 16:17, 25 April 2017 (UTC)

It is available in some wikis where they are currently testing it ... 197.218.83.13 (talk) 16:27, 25 April 2017 (UTC)

Is it available on wikipedia? RIT RAJARSHI (talk) 16:33, 25 April 2017 (UTC)

Yes, but it appears randomly because they are testing it with some anonymous users, see (Beta Features/Hovercards#Project-level rollout discussions), for example, it appears for me in catalan wikipedia (

Ca:

) . It will probably be available for all once it is fully deployed. 197.218.83.13 (talk) 16:48, 25 April 2017 (UTC)

Emphasis not being preserved in some pages

For some odd reason the emphasis found in some articles is not being preserved in the preview being shown through hover cards. For example, see below.

Note : It's assumed that Hover cards has been enabled before you follow the steps. And, of course, that you have been logged in.

Steps to reproduce

1. Open the w:Real coordinate space article.
2. Search for the words several (n) real in the first paragraph.
3. Hover over the letter n found inside the parantheses.

Expected results

The text is free variable emphasised, as found in the w:Free variables and bound variables article.

Actual results

The text isn't emphasised. Kaartic ^[talk] 12:00, 27 April 2017 (UTC)

Hovercard Summary

I have Hovercards enabled and, so far, I've enjoyed the feature despite its limitations. I want to point out two things that I wish should improve in the Hovercards.

1. Whenever the preview of a page materializes on the screen, the first couple of words that match the article name exactly (regardless of capitalization) are in bold. If they are not, then the text is plain. I find this to be a little bit inconvienient, since the first couple of words do not neccessarily highlight the article even though I can find the topic easily. I believe that instead, when the Hovercards are previewed, the text shown is on par with the article exactly.
2. Like this topic here, the Hovercards should show a little more of the article itself because, most of the time, I have to go to the article itself and this makes Hovercards weak as an alternative (if so). Also, it fails to explain most of the subject, both on the fault of the introductory section of a Wikipedia page and the Hovercard's limitation on showing 'that' much of the intro. Sheldon.andre (talk) 19:34, 10 May 2017 (UTC)

12 May 17: Missing Hovercard preview text issue

I have had Hovercards enabled for over a year. This morning several of the prominent links on the Main Page are not working, displaying "

Looks like there isn't a preview for this page

Read" with a sad-face icon. These are links which yesterday were producing Hovercards just fine. Has something changed or could it be a local issue? Careful With That Axe, Eugene (talk) 07:45, 12 May 2017 (UTC)

Yeah, me too. By the way, I'm seeing it on en:wp, I don't know where you're having the problem. It isn't consistent, only affecting some pages. I don't have enough technical experience to have any clue what's going on, but might it be some kind of database or cache problem? Tamwin (talk) 15:54, 12 May 2017 (UTC)

It seems to be a issue on the Featured Article, the Kuiper belt. I noticed it's gone to other pages that used to work fine before. It may have started today as well, as the hovercards were working fine before. JJBers Public (talk) 16:43, 12 May 2017 (UTC)

This issue was reported earlier today as phab:T165172 and phab:T165161. A fix is rolling out as we speak. —TheDJ (Not WMF) (talk • contribs) 18:05, 12 May 2017 (UTC)

Is "Looks Like There Isn't A Preview" always needed?

I'd suggest that rather than a pop-up saying "Looks Like There Isn't A Preview for this page" don't pop-up anything. (i.e. if nothing useful to say, say nothing) - because I'm seeing a lot of these and it's driving me mad (so I'm stopping using the thing. ~ PsamatheM (talk) 19:11, 12 May 2017 (UTC)

Summary should finish with full ended sentence

I think it would be cleaner to look at these Hovercards if they finished with the end of a sentence. In my opinion an unfinished sentence always results in clicking on the link – which makes the Hovercard useless because I want to see the end of the sentence to understand what an article is about.

To give you an example, this is what I get after hovering over "Anisa Mohammed":

Anisa Mohammed is a Trinidadian cricketer. A right-arm off spin bowler, she has played for both the Trinidad and Tobago and the West Indies women's cricket teams. Since her international debut at 14 years of age she played in 101

Who wouldn't want to know where she played in?

When reading only "Anisa Mohammed is a Trinidadian cricketer. A right-arm off spin bowler, she has played for both the Trinidad and Tobago and the West Indies women's cricket teams.", I might have gotten everything I wanted to know. Avonsoda (talk) 16:50, 19 May 2017 (UTC)

The reason this is done must be these two main reasons:

1. sentences vary in length (some are very short, some long) so the Hovercard/Page Preview could end up too big/small
2. it could be difficult and cause disagreement choosing which sentence to stop at, with a summary text possibly failing to include enough information

I hope you understand my points that may be why your method isn't used. Edwardj 123 (talk) 20:09, 19 May 2017 (UTC)

Not enough content in the preview box

In german articles if you get a preview it's often too less content to understand. It would be very useful, if the Hovercard would view the whole first passage of the linked article, wich ususually contains the most needed information. But at the moment it mostly shows the last viewed sentence cut off at the middle an its often too less information. I think the boxes could be much bigger (both higher and wider); on the most devices there would be enough space for that. Munichviolin (talk) 14:00, 26 May 2017 (UTC)

Yes, I think you are right. Inalol (talk) 18:48, 26 May 2017 (UTC)

Maybe a setting controlling the size of the Page Previews/Hovercards feature box could be created so users can click the settings icon and select "normal", "larger" or "smaller".

Also see the following related issues:

• https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2017#h-Too_much_content-2017-05-26T19%3A36%3A00.000Z (Too much content - the other size change)
• https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2017#h-Summary_should_finish_with_full_ended_sentence-2017-05-19T16%3A50%3A00.000Z (Summary should finish with full ended sentence) Edwardj 123 (talk) 21:22, 5 June 2017 (UTC)

Too much content

Okay if you get too much content, you can turn this feature off. Inalol (talk) 19:36, 26 May 2017 (UTC)

Maybe a setting controlling the size of the Page Previews/Hovercards feature box could be created so users can click the settings icon and select "normal", "larger" or "smaller".

Also see the following related issues:

• https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2017#h-Not_enough_content_in_the_preview_box-2017-05-26T14%3A00%3A00.000Z (Not enough content in the preview box)
• https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2017#h-Summary_should_finish_with_full_ended_sentence-2017-05-19T16%3A50%3A00.000Z (Summary should finish with full ended sentence) Edwardj 123 (talk) 21:26, 5 June 2017 (UTC)

Previews Cut-Off

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It can't be that hard to make an algorithm that makes the preview stop at a period instead of mid-sentence. ΣΨΦ (talk) 16:37, 31 May 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Graphic / inappropriate summary images [duplicate]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hovercards often show graphic images without warning. ΣΨΦ (talk) 16:38, 31 May 2017 (UTC)

The images are needed as part of the subject summary - this is stated in the purpose of this beta feature.

If you think the images are inappropriate, read this counter-argument from topic https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2015#h-Some_pictures_may_be_%22_inappropriate%22-2015-10-19T05%3A21%3A00.000Z (Some pictures may be " inappropriate") to understand the point (key reasons in bold):

This is not an issue concerning the hover cards. As long as pictures are shown there might be "inappropriate" ones, depending on your culture and sensibility. And I guess showing pictures is an intended function. There is no way the pop up could decide which one is okay and which is not.

Also, there can't be that many sensitive articles so it's unlikely you would hover over a link to one. I'm closing this topic as a duplicate. Edwardj 123 (talk) 21:09, 5 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Works Great

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Besides the previews not ending with a "period" I really enjoy them. PayneAckerson (talk) 08:43, 2 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How is the "Read" link in Page previews useful

It seems that "Page previews" shows a "Read" link for articles for which it couldn't display a preview. I'm not sure how it would be of any use when the page preview itself is displayed only when the user hovers over the link to that page. Doesn't it sound repetitive ? Kaartic ^[talk] 13:16, 12 June 2017 (UTC)

Err no. There are many times that something that looks like a link might not be:

• Using css for example someone could create text that looks a lot like a link, but isn't
• It could also in the future indicate that the page is blank, and not show the read button (it would be useless to navigate to a blank page only to find out it is blank)
• A page could potentially be deleted while the user is hovering over it, and or simply show old cache, in which case, one can't read it, and one won't know because it hasn't changed to red.

It is worth it in general to make page previews smarter in those contexts. 197.218.80.218 (talk) 13:30, 12 June 2017 (UTC)

That doesn't seem warranting.

Using css for example someone could create text that looks a lot like a link, but isn't

In that case Page previews wouldn't display a preview for you in the first place. It should work only for valid wiki links.

It could also in the future indicate that the page is blank, and not show the read button (it would be useless to navigate to a blank page only to find out it is blank)

I have rarely seen blank pages in wikis a lot.

A page could potentially be deleted while the user is hovering over it, and or simply show old cache, in which case, one can't read it, and one won't know because it hasn't changed to red.

That seems to be a once in a blue moon event. I guess they don't think of these while developing features like these. Kaartic ^[talk] 17:25, 12 June 2017 (UTC)

Wikipedia In Spanish

Para cuando Hovercards en la versión en español de Wikipedia. 189.238.119.103 (talk) 21:29, 28 June 2017 (UTC)

Has the community requested that the feature be enabled there? If so, then they can file a request in Phabricator, with a link to a community discussion about enabling it. Whatamidoing (WMF) (talk) 19:52, 4 July 2017 (UTC)

Primero, soy la misma ip que preguntó esto. Segundo, lo siento, no estoy seguro de si lo han pedido. Yo solo había preguntado por curiosidad. Gracias por la respuesta. 189.238.60.30 (talk) 15:29, 5 July 2017 (UTC)

Hovercards in Arz and Ar

I find it good looking and informative enough. If I am reading an article, I don't necessarily have to visit each and every linked page. I can now know briefly what this "phrase/word" is about (whether a title, a person or anything else) and just go on reading. QLailaS (talk) 19:00, 13 July 2017 (UTC)

I find it useful when viewing an edit preview for an article, as it allows me to easily verify if any wikilinks I added are working. Name goes here (talk) 01:11, 17 July 2017 (UTC)

Change font size

Would you consider a feature that allows the user to modify the font size of the hovercard?

My monitor resolution is not the average (32" at 1366x768) so the fonts are shown a bit disproportionated in comparision to average 22, 27, and so on in full hd. I think it might be useful for some people though despite not having the so named disproportion LLANO (talk) 21:59, 23 July 2017 (UTC)

Image alt text with links

Hovercards are causing the title text of the image links in w:en:Template:NYCS SSI to be hidden. Would it be possible to show the tooltip as well as the hovercard? Jc86035 (talk) 15:22, 10 August 2017 (UTC)

My guess is that showing tooltips would be hard (but perhaps I'm wrong).

That template appears to show a dot or diamond, and to be used to convey important information. Completely apart from the problem of relying on tooltips when Hovercards shows the linked template rather than the tooltip, have you talked to the w:en:WP:ACCESS editors about whether a small icon with a tooltip is the best way to present that information? Whatamidoing (WMF) (talk) 20:26, 11 August 2017 (UTC)

This question has also made me wonder how Hovercards interacts with templates that are used to build tables. Whatamidoing (WMF) (talk) 20:30, 11 August 2017 (UTC)

I don't think it's a very good way of presenting the information, but usually there's a legend describing what they mean, such as this one. Hoever, it gets confusing since it's difficult to remember what they mean (there are at least 18 options of monochrome circles and diamonds, with some symbols being reused). Is it possible to unhide the title= attribute only if the ‎<a> contains an ‎<img>?

How would interaction with table-building templates be different to normal behaviour on link hovers? Jc86035 (talk) 06:03, 12 August 2017 (UTC)

I was surprised that hovering over an image in the table at w:en:Staten Island Railway#Main Line stations would link me to w:en:List of New York City Subway services#Time periods, so now I'm wondering what other odd behaviors might happen from some of these complicated templates. Whatamidoing (WMF) (talk) 22:41, 12 August 2017 (UTC)

I think this template is an outlier, since this sort of link is usually discouraged by the Manual of Style (at least on enwiki), and most other transport systems don't have this sort of convoluted time period system. The Staten Island Railway has the same operator, rolling stock and fare as the New York City Subway, so it's not too unexpected. Jc86035 (talk) 05:55, 13 August 2017 (UTC)

I just created a task for the alt text with links issue: https://phabricator.wikimedia.org/T173984

Should I create one for the second for tables generated by templates? I'm not sure I fully understand the problem there. :) CKoerner (WMF) (talk) 21:11, 23 August 2017 (UTC)

I don't think the table thing is a software bug, more to do with confusing article structure. Jc86035 (talk) 12:06, 24 August 2017 (UTC)

Chris, I don't think that you should file a second bug report. It might make a fun test case, but I don't think that there are any bugs there. Whatamidoing (WMF) (talk) 17:00, 24 August 2017 (UTC)

Templates not rendered correctly in hovercard

See (e.g.) the link to Chakavian at https://en.wikipedia.org/wiki/Dual_(grammatical_number)#Slavic_languages.

The pronunciation language is not displayed at all (note the two apparently stray commas).

Hovercard:

Chakavian or Čakavian , , is a dialect of the Serbo-Croatian language spoken by a minority of Croats...

Page:

Chakavian or Čakavian /tʃæˈkɑːviən/, /tʃə-/, /-ˈkæv-/ (Serbo-Croatian: čakavski [tʃǎːkaʋskiː], proper name: čakavica or čakavština [tʃakǎːʋʃtina],own name: čokovski, čakavski, čekavski) is a dialect of the Serbo-Croatian language spoken by a minority of Croats... Matttoothman (talk) 19:16, 16 August 2017 (UTC)

Thanks for the note. There is currently work happening to make Page Previews work better with text that is included via templates. One big part of this is chaining how we generate these previews to not eat up some of the content. :) There's still much work to be done, but please know we hope to address issues like the one you have described. More information can be found on Phabricator. CKoerner (WMF) (talk) 21:04, 23 August 2017 (UTC)

Status on English Wikipedia?

I noticed today that Hovercards were no longer appearing on English Wikipedia. When I went to check my preferences page, I could not find it listed in the Beta section (nor in the regular preferences tab, as far as I could tell). Is there any way I could get the hovercards back? It's one of my favorite features! 68.82.224.203 (talk) 03:14, 1 September 2017 (UTC)

Same here :-( as on the German WP. 2001:A61:22F5:1F01:6267:20FF:FE09:9AA4 (talk) 03:59, 1 September 2017 (UTC)

It's a bug: https://phabricator.wikimedia.org/T174724 —TheDJ (Not WMF) (talk • contribs) 09:53, 1 September 2017 (UTC)

Feedback

First of all, it appears unfortunate that - apparently - there was no (prominent) public announcement of this test on dewiki. How is the email response team (OTRS) supposed to respond to questions about a feature it doesn't even know is enabled? I hope we haven't missed some announcement, but those of us who discussed the matter have not noticed anything like that.

Second, I'm relaying the user's feedback to you: "I find the newly introduced PopUps extremely annoying, because they pop up at the slightest touch while scrolling through the article and cover the text I actually want to read. I prefer the previous behavior, where I click on blue links only if I want to read the corresponding articles." Pajz (talk) 06:22, 5 September 2017 (UTC)

Thanks for the feedback Pajz. I'm assuming, and please correct me if I'm wrong, that the test you are referring to is the recent A/B test? I left a notice on the Technik/Werkstatt letting the German community know of the test. If there was better venue I could have used to alert folks, please do let me know. Sorry for the confusion. CKoerner (WMF) (talk) 18:58, 5 September 2017 (UTC)

Hovercards for Wikipedia links on external pages

Hi! First of all i think this feature is awesome and makes researching much more enjoyable!

Anyway, I was immediately wondering if it would be possible to extend this feature on external, non-wiki pages. For example by having a plugin script that people would then link in their website to enable this feature. Or any kind of external interface for the information included in the hovercard. Is anyone here involved in development and/or planning and knows if this might become reality?

Greetings, Jo (total wiki greenhorn) ;) Jo5chp (talk) 15:00, 9 September 2017 (UTC)

Not compatible with ImageMap

Hello,

The popups don't appear on imagemaps, any idea why? 195.80.103.225 (talk) 22:37, 11 September 2017 (UTC)

imagemaps are not normal links. —TheDJ (Not WMF) (talk • contribs) 06:15, 12 September 2017 (UTC)

What I’m missing compared to Navpopups

https://phabricator.wikimedia.org/T109796

I’m considering switching from Navpopups to Hovercards, so I had a look on what features I’d miss:

• Section previews (phab:T65792)
• Section previews when hovering a link in the TOC
• Diff previews, especially from the watchlist (I’m reading my watchlist almost exclusively that way) and page histories
• Because the image is so large and makes the text appear in different locations, it takes significantly longer to focus on the beginning of the preview text
• An overview of the page history (on hovering a link in the preview box)
• An overview of a user’s recent contributions (on hovering a link in the preview box)
• "Previews" (actually, full content) of references (solved by Reference Tooltips, actually nicer than Navpopups)
• The ability to "hover through" categories (especially on commons)
• Getting further information (basicly the information template, Navpopups simply shows the template source code in this case) on files in categories (from files embedded in articles that might get annoying, but could maybe also be useful)
• In the case of no lead paragraph… (as I’ve read over here) just preview whatever’s next?
• Seeing where a redirect leads to
• Seeing the first few entries of a disambig page

(thanks for fixing the shitty formating from this Flow thingy and the link to the overview phab ticket, kind strangers :-) )

If this were a regular talk page, I’d just say „feel free to add phab links to the list items“, but I’m not sure whether that’s possible in Flow… Anyway, I hope this feedback is helpful :-) Nenntmichruhigip (talk) 12:19, 14 September 2017 (UTC)

yoruba language

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

yoruba language is a kind of language that is being spoken in nigeria and the people that speak yoruba are called the yorubas, i will just like someone to work with me on how i can make the history of yoruba known and be studie in other country as a foreign language as english language is made known in all the world. Dunremi (talk) 13:45, 28 September 2017 (UTC)

@Dunremi, I'm afraid you've ended up in the wrong location. Perhaps someone on the Yoruba Wikipedia can help you. I'm marking this as resolved as it is not on-topic and wish you the best! CKoerner (WMF) (talk) 19:09, 28 September 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

PDF/DJVU page images

So for embedded PDFs or DJVUs from books, a specific page is often used with the page= syntax. However, Hovercards just uses the first page. See en:The Waste Land for an example. Opencooper (talk) 02:36, 14 October 2017 (UTC)

Preview images of maps with a position marker

The german wikipedia has very often maps of some area with a position marker, the map is created from some image and an overlay with the position marker that seems to be created magically from wikidata.

An example of such a map is de:Muro_Lucano

When a hovercards pops up, the position marker is not shown which is IMHO not very helpful. You can reproduce that hovercard in the first line of de:Liste_der_Bischöfe_von_Muro_Lucano. Wurgl (talk) 09:47, 28 October 2017 (UTC)

When I go to https://de.wikipedia.org/wiki/Muro_Lucano and click on the map, I expect a page with a bigger version of the map with the position marker still displayed. But all I get is a map of a country without a position marker which is not very helpful. In my opinion that is the actual problem to solve, and not creating some workarounds in Hovercards/Page-Previews code. Malyacko (talk) 09:26, 29 October 2017 (UTC)

IPA is not properly removed in link previews

IPA templates (without brackets) are not properly removed in link previews. They leave an extra space.

Example: page – link preview

Example 2: page – link preview

Brackets, on the other hand, are properly removed, and no space is left.

Please fix this by setting Hovercards to remove the space before an IPA template. · • SUM1 • · (talk) 22:33, 22 November 2017 (UTC)

Post-nominal letters are not properly removed in link previews

Post-nominal letters are not properly removed in link previews. Commas surrounding the post-nominal letters are left.

Example: page – link previews

Example 2 (with "post-nominals" template): page – link preview

Example 3 (with two commas): page – link preview

Please fix this by setting Hovercards to remove any commas surrounding post-nominal letters. · • SUM1 • · (talk) 16:02, 24 November 2017 (UTC)

Please report bugs in phabricator (And the blurb is produced by TextExtracts btw, hovercards just shows it). —TheDJ (Not WMF) (talk • contribs) 19:05, 24 November 2017 (UTC)

Thanks @SUM1 for the reports. I believe issues like the ones you mentioned will be corrected with some upcoming work to change the way Page Previews display content. Right now it uses TextExtracts to try and pull out bits of content to make the preview more succinct. It doesn't always work as you noticed. There is current work to change the way the feature generates the preview, resulting is more consistency in representing the content of the article. Work is progressing, but I don't have a solid timeframe for you at the moment other than hopefully soon. :) I'm bookmarking these examples and will return to them once I can test them against the new code. CKoerner (WMF) (talk) 16:01, 6 December 2017 (UTC)

Thank you · • SUM1 • · (talk) 17:17, 6 December 2017 (UTC)

Hatnotes are shown in link previews

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I wouldn't want information about disambiguation displayed in a link "preview" for the following reasons,

1. It takes up the limited space giving me less of the useful information.
2. It's not worth showing the hatnotes like (For X, see ...) in the previews. I believe that the articles links to the one that's relevant to it. So, there's no need for any information about disambiguation link. Kaartic ^[talk] 06:56, 5 December 2017 (UTC)

Forgot the example, sorry. Try hovering over the "SHRDLU" link in the third paragraph of the w:en:Natural language processing article's History section. Kaartic ^[talk] 06:59, 5 December 2017 (UTC)

@Kaartic that's a problem with the article not identifying that fragment as a hatnote. I fixed it —TheDJ (Not WMF) (talk • contribs) 08:47, 6 December 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

December 2017 status?

Is this feature currently enabled at all? None of the advertised options seems to be present. I've tried different wikipedias, different users (incl. anon), different browsers. It is not available anywhere I look. I've looked at the Phabricator pages linked here under "Known Issues" and became none the wiser. Bdijkstra (talk) 10:44, 5 December 2017 (UTC)

It's currently being moved I believe, and I think they didn't update the documentation yet. On Wikipedia you can find it in your Preferences -> Appearance -> Page previews

On some other places it might be in the Beta tab —TheDJ (Not WMF) (talk • contribs) 08:44, 6 December 2017 (UTC)

Ah thanks, I was expecting to find it under Gadgets (or Beta). Bdijkstra (talk) 09:31, 6 December 2017 (UTC)

Thanks for the reminders folks. I updated some of the documentation and will continue to do so. The feature is in production on all Wikipedia's but two and not available as a Beta Feature (in the Beta feature tab in preferences) anywhere. Sorry for the confusion. CKoerner (WMF) (talk) 23:23, 7 December 2017 (UTC)

One of the reasons why I had trouble enabling feature was because the link "Edit preview settings" is no longer present at the bottom of wikipages. A key difference with navpopups is or was:

"Page Previews will be available to all users, not just logged-in users"

How can anonymous users enable the feature now? Bdijkstra (talk) 14:45, 8 December 2017 (UTC)

It's there for me, if I use a private browsing session and do not log in.

https://phabricator.wikimedia.org/F11694757 —TheDJ (Not WMF) (talk • contribs) 15:15, 8 December 2017 (UTC)

Not on all Wikipedia's. I've checked a handful of major languages, but I saw the link only on enwiki and dewiki. Bdijkstra (talk) 15:30, 8 December 2017 (UTC)

I'm 99% certain that the link doesn't appear in the footer until you disable Page Previews via the cog setting. @OVasileva (WMF) can you please confirm? CKoerner (WMF) (talk) 22:17, 8 December 2017 (UTC)

Sorry for the confusion. I was looking for the link without realising that in the mean time, the feature has been turned on for anonymous users. So everything seems to be working now (unlike yesterday). Bdijkstra (talk) 22:31, 8 December 2017 (UTC)

No preview shown for a link to a redirect page??

Tracked in Phabricator
Task T182953

I think previews are shown for links even if they are just redirects. If my previous statement is true, I recently noticed an outlier. Hovering over the w:Core memory link in an image text (A portion of a core memory with a modern flash SD card on top) in w:Random Access Memory shows the Looks like there isn't a preview for this page message in the popup.

I specify this as an outlier because in the same image text there's a link to the w:SD card article which is also redirect. Hovering over it does show a preview!

Any reasons for this odd behaviour? Kaartic ^[talk] 07:40, 9 December 2017 (UTC)

It is likely due to the fact that the redirect is categorized (without a hidden category), making the intended behaviour ambiguous. Should the preview show the category or should it redirect, what about cases where it contains simple text?

In fact, a redirect is simply a page with a redirect markup. It could potentially be a full page with lots of content as long as the first section contains that markup. It is an unfortunate result of earlier developer's misguided decision to allow metadata inside a page. 197.218.81.8 (talk) 09:14, 9 December 2017 (UTC)

In any of the following cases,

• a redirect page (that only contains #REDIRECT ...)
• a categorized redirect page
• a redirect page with simple text (is it even possible?)

I might not care if the the preview of the page to which it redirects is shown. That's because, I expect the preview to give more information than I could get from the link text. I don't think the information such as,

• categories to which the page that redirect page belongs
• simple text in the redirect page (if it's possible)

shown in the preview would be more useful than the preview of the page to which it redirects. Kaartic ^[talk] 07:30, 10 December 2017 (UTC)

You're missing the point that mediawiki is an interface / software that is in a perpetual state of conflict. It attempts to cater to both readers and editors and can never really cater properly to both of them due to the inherent difference in the characteristics of those users.

Showing preview of the redirect itself may be sensible sometimes for an editor, but may not be so for a reader. Moreover, a redirect may be to the wrong target, and simply confuse both editors and readers.

Anyway, as far as this thread is concerned it seems to be a clear issue, because there are other redirects that have categories and work properly. Perhaps all it needs is a simple edit to refresh the cache. 197.218.80.253 (talk) 09:54, 10 December 2017 (UTC)

IP I think you misread. Kaartic wasn't asking to see categories or text on the redirect page. They were merely responding to your point that it would be plausible to show categories or content on redirect pages, acknowledging that showing-something is better than a "no preview available" showing-nothing. I think we all agree the best behavior is to ignore anything on the redirect page, and just show a preview of the redirect-target page. People expect preview to show whatever clicking-the-link will show.

I tested somethings, trying to fix it:

• Purging the redirect page didn't work.
• Purging the page pointing to the redirect didn't work.
• Null-editing the redirect page didn't work.
• Null-editing the page pointing to the redirect didn't work.
• A dummy edit[10] to the redirect did fix it!

Weird. This should definitely be investigated. It could be affecting other pages. In fact there is no clear basis to conclude that it's related to the page being a redirect. It could be affecting regular article pages. Alsee (talk) 11:04, 10 December 2017 (UTC)

There will always be edge cases where it makes sense to show that dialog, e.g. if it can't possibly interpret the page such as the target page of a redirect being deleted, target page never existing in the first place, no first section on a particular page, and so forth.

"No preview" seems to be shown whenever it can't interpret or read the preview. It could be caused by any number of things, e.g. an error while reading the page, or storing the summary, or simply an inability to parse the content properly.

It is probably not worth overthinking it unless it can be consistently reproduced even after a simple page edit. 197.218.80.253 (talk) 15:06, 10 December 2017 (UTC)

A dummy edit to the redirect did fix it!

—Alsee

Now that's what I call surprising. Of course as large number of components might be involved in showing a preview, this might be something that cannot be easily tracked down. Anyways, it's up to the developers to decide. May be we should file a ticket on phab and let the developers decide for obvious reasons (they know a lot more than we do about how previews are shown). Kaartic ^[talk] 15:35, 10 December 2017 (UTC)

Formulas are not properly displayed in link previews

Formulas ("math" markup) are not properly displayed in link previews. The formula is duplicated with "{\displaystyle }" shown around it, among other changes (like added underscores), powers are incorrectly shown as full numbers and bracketed letters are not shown.

Example: page – link preview

This is a response to CKoerner (WMF)'s reply on this topic. · • SUM1 • · (talk) 12:59, 9 December 2017 (UTC)

@SUM1The updated code is on the beta cluster. Looking at some of the examples, things look much improved. I'll let you know when this reaches the actual wikis! CKoerner (WMF) (talk) 20:57, 21 December 2017 (UTC)

@CKoerner (WMF) Damn, that looks great. Looking forward to it. · • SUM1 • · (talk) 22:23, 21 December 2017 (UTC)

Possibly the same bug, not sure: page and link preview. The "O(log n) amortized time" text appears as "O amortized time" in the preview.

Perhaps this is a result of the "O" being a link immediately followed by parentheses? Itamarcu (talk) 10:53, 10 January 2018 (UTC)

Thanks for the report @Itamarcu! This issue is fixed as of March 5, 2018 OVasileva (WMF) (talk) 15:41, 7 March 2018 (UTC)

@Itamarcu Yes, that would simply be a case of link previews removing brackets and their contents. · • SUM1 • · (talk) 15:19, 10 January 2018 (UTC)

Trying to implement on a private wiki (corporate intranet): doesn't work

We use Mediawiki 1.29.1 for a corporate intranet, and I am trying to get Page Previews working on it. I have installed the mandatory extensions and verified that all are working. Yet after turning the feature "on" in my preferences, I do not see any previews at all.

Any idea what I am doing wrong, or not doing, or doesn't this work for a private intranet? 204.174.222.21 (talk) 19:42, 9 December 2017 (UTC)

Can you please see if the settings (now documented!) I replied with in this thread make any difference for you? CKoerner (WMF) (talk) 15:43, 11 December 2017 (UTC)

Hmmm .. no they do not. The first setting has incorrect syntax, btw - a colon instead of semi-colon at the end.

What has now happened is that the option to enable Page Previews has vanished from Preferences for logged in users (the only kind we have). 24.248.254.194 (talk) 22:45, 12 December 2017 (UTC)

Link previews are occasionally only one sentence long

Link previews are occasionally only one sentence long, not showing the full lead section of a page.

Example: page – link preview

On many other occasions, I have seen them display the message that there is no link preview for a page even when the page has text in its lead. I cannot find any examples at present.

This is a response to CKoerner (WMF)'s reply on this topic. · • SUM1 • · (talk) 22:44, 21 December 2017 (UTC)

Hatnotes which are not organised as templates are shown by mistake in link previews

Hatnotes which are composed of an indent (:) plus italic text are shown by mistake in link previews. However, the link preview correctly removes hatnotes which are made from the various hatnote templates, such as {{hatnote}}, {{About}}, {{For}}, etc.

Example: page – link preview

This is a response to CKoerner (WMF)'s reply on this topic. · • SUM1 • · (talk) 23:00, 21 December 2017 (UTC)

From an editor-perspective, this could be seen as a good thing (or at least a beneficial aspect), because it helps us notice things which need to be fixed! Admittedly not in the cleanest way possible, but...

I've fixed that instance. –Quiddity (talk) 17:22, 22 December 2017 (UTC)

@Quiddity You're right, and I fix it every time I come across it, but it's how often it comes up that made me consider it a problem. I can't count the times I've had to fix this format of hatnote. For this reason, I was thinking it could be easier to configure a way to not show it in link previews instead, but of course it's up to the developers. · • SUM1 • · (talk) 17:28, 22 December 2017 (UTC)

The answer here is definitely to fix the instances of incorrectly-formed hatnotes, rather than to hide the problem in any way. I've personally fixed thousands of these, and as far as I can tell this is really a problem that needs human effort to clean up: the badly-formatted cases are too inconsistent to cleanly handle automatically. Beyond showing up badly in previews, the bad :'' format also represents inferior formatting for accessibility.

I'd like to mention in particular some regex-based searches for these sorts of issues saved in my sandbox (permalink).

If we get more people together fixing them, we could reduce the problem significantly. If enough people are interested, we could even start a WikiProject to coordinate effort. I see hatnotes as a key part of the template infrastructure and have pushed a lot of effort into making them more functional and standardized (e.g. creating Module:Hatnote list, or umpteen TfDs to cut down on needless template sprawl). {{Nihiltres|talk|edits}} 01:22, 23 December 2017 (UTC)

Re: "we could even start a WikiProject [...]" - at Enwiki, this would best be handled by WikiProject Disambiguation. I suggest copying your great sandbox list, into a new sub-section at w:en:Wikipedia:WikiProject_Disambiguation#How_to_help.

(Also, kudos on your great "Notes from a survey [...]" table :-) Maybe that could become a WP:WPDAB subpage, or talkpage section, to enable collaborative analysis?) –Quiddity (talk) 19:27, 24 December 2017 (UTC)