Thanks for your thoughts @jcrespo!

• The "gear" icon on the preview panel links to https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering For me this is highly confusing, I think it should link to id #mw-prefsection-rendering-reading so the enable/disable preferences are on top.

Makes sense. I've created T192772: Settings cog should use modal used for anonymous users to track it

• I feel the area that is clickable on the panel is strange- I guess it is only on the part that is 100% visible, and that a gap has to be added between the preferences and the button, but maybe the gap can be just a corner on the right-down, or at least extend the clickable parts a bit more towards the bottom part? Image attached:
  

This definitely looks like a bug. I've reproduced myself with today's https://es.wikipedia.org/wiki/Wikipedia:Portada hovering on historia del chocolate. It seems like the clickable area is not appropriately shaped.

I've created T192773: Entire page preview should be clickable to follow up on this.

Thanks for your comments, lets see what product and design think about the other ones!

I'm tagging the backlog to have some discussion here. Ping @ovasileva

I have one more suggestion:

• If technically possible, disable temporarily the page previews while a text selection is going on. One use case for wikipedia is to copy and paste text (yes, I guess those school assignments are a use cases). When doing that, probably the user doesn't intend to get more information if it stops on a text. This is much more arguable, as it may be tuned with the delay to appear- so not 100% sure about it.
• In the feature request side of things, maybe being able in the future to disable images could be considered. [] Enable page previews []enable page previews without images []disable page previews

Could the feature be enabled at other projects on links towards wikipedias (e.g. Wikidata, but only for interwiki links, wikivoyage, but only for [[w: ]] links, etc.? That should be easier than making summaries work for other types of content (I am just guessing)?

I don't see any technical reasons why "intrawiki links" would not be possible, however I believe we would need to parse the href of every link on hover to determine which wiki it belongs to. However, this would require additional config and code complexity to disable the normal links case while the summary endpoint was missing.

Tagging design to get some of their thoughts.

@ovasileva @Jdlrobson are y'all okay with closing this out? If so feel free to do so :)
I believe it has served its purpose, as individual tasks have been created to represent the various actionable items (T192773 and T192772)

Thank you!

There is only one misunderstanding, I didn't request to generate previews of Wikidata or Wikioyage projects as those task propose (I think that is secondary and more difficult), but to enable ir (or allow enabling it) for Wikipedia links on non-Wikipedias (internal wp:en: / :en links, for example). E.g. Wikivoyage and Wikidata and wiktionary may have a lot of Wikipedia links. E.g., on https://www.wikidata.org/wiki/Q2, the interwikis could show the Wikipedia previews.

Those are already supported on the backends and the data (previous) is already stored, so in theory (of course, I don't really know for sure) it should be simpler. CC Services

In T192710#4618292, @jcrespo wrote:

There is only one misunderstanding, I didn't request to generate previews of Wikidata or Wikioyage projects as those task propose (I think that is secondary and more difficult), but to enable ir (or allow enabling it) for Wikipedia links on non-Wikipedias (internal wp:en: / :en links, for example). E.g. Wikivoyage and Wikidata and wiktionary may have a lot of Wikipedia links. E.g., on https://www.wikidata.org/wiki/Q2, the interwikis could show the Wikipedia previews.

I believe this is tracked in T67117

Thanks!