Talk:Reading/Web/Projects/Related pages/Flow

This is a place to discuss feedback for the Related pages beta feature (on mobile or desktop).

Here is a summary of issues raised along with proposed responses:

Reading/Web/Projects/Related pages#Initial Community Feedback

Here is a proposal for moving forward:

Reading/Web/Projects/Related pages#Proposal for moving forward

An RFC asking for feedback to the proposed next steps also here: m:Talk:Requests for comment/Related Pages

There are some outdated paragraphs, and the whole vibe is that no one has updated this page since 2016. May I ask for some updates?

Hi! What would you like to see updated in particular? This page is pretty much an archive indeed...

@SGrabarczuk (WMF) I came here to read about the Related pages feature on mobile. I assume that this page documented the work as it was being done, while I am looking for a stable description (like a Wikipedia article that has separate sections for history of the topic and its current state, without saying e.g. "this is too much of a question mark as of February 24, 2016"). If this is an archive, is there maybe another page that documents the feature as it currently is?

At https://meta.wikimedia.org/wiki/Requests_for_comment/Related_Pages it says "Editors may override these software selections by adding up to three {{#related: page title}} to the page." I tried to do this at Cincinnati chili and it doesn't seem to be working -- the articles I suggested aren't being offered. Instead it's still offering a combination of odd suggestions -- pages that article already links to, barely-related articles, actually bad suggestions, etc. Am I doing something wrong? I couldn't figure out where to find documentation for that template. Thanks for any assistance!

I started trying to fix it because one of the suggestions was a similar dish that has been tagged for notability and lack of sources for years and which certainly should never have been suggested to anyone. Are we working to improve these suggestions?

Huh, now it's working...maybe it just needed a bot to come by or something? So ignore that first para, lol. I'm more interested in whether we're working on trying to prevent such issues, thanks!

Bizarrely, it is now again NOT working. What the heck? Why would it start working, then stop?

Sounds like a bug relating to caching. Could you please open a bug report on phabricator.wikimedia.org ?

I've done so, thanks!

An article about a xenophobic party was suggesting as a related article a biography of a person not related with the party. This has provoked a complain of this person, a case to be treated per en:Wikipedia:Biographies of living persons. I have solved it with related magic word. I think there should an easy way to blacklist an article not to be shown as related to another article.

Hi @Vriullop, thank you for reaching out and we appreciate your suggestion. This is indeed an issue which we have thought of in the past as well. Unfortunately, we are not planning any further development on related pages at this time. Removing articles which might not be appropriate was one of the main reasons behind us building out the magic word in the first place and, unfortunately, we think it’s probably the only solution we will have for the time being.

Hello, i'm an enwiki editor interested in using this on desktop so I can be aware of what mobile users are seeing and just general interest/utility. How would I install this for myself (is there an importScript or mw.loader.load line I can add to my common.js)? I used to have this enabled via the Beta features tab so it should technically be possible.

I think you can do this by just adding the following code to your user scripts:

mw.loader.using('ext.relatedArticles.readMore.bootstrap')

Worked like a charm. Thanks a lot!

Eg, i'd like to create a tag, MyTag, and then relate several pages with {{#related:MyTag}}. Is that possible?

I'm guessing it could be done with a common page that they all point to, where the hub page is called "MyTag". Maybe could be a sub-category page.

We want to tag our articles (topic-tags, not revision-tags). And then display "Related Articles", based on those tags.

This article describes a method using SemanticWiki, https://clkoerner.com/2012/08/28/use-semantic-mediawiki-semantic-forms-to-create-a-folksonomy-for-tagging-related-pages/ but that seems a heavy solution, since we don't need any other SemanticWiki features. Would prefer a simpler method.

Can't use Categories, as we're already using Categories as Categories, for organizing and TOC. We consider Categories and Tags to be different concepts. That Folksonomy article agrees. Eg:

• Category is Fruit.
• Title is Oranges.
• Tags are citrus, segmented, juicy, vitamin C, cold prevention, breakfast

Or

• Category: Books
• Title: Cien Años de Soledad
• Tags: Spanish, surrealism, Colombia, magical realism, Latin American

Tags vs. Categories:

• Non-hierarchical: We use Category as a hierarchical organizing structure. We want articles to appear in only one Category in TOC, but articles can have multiple tags. Tags are non-hierarchical, and can apply across different Categories.
• Permissions: We want separate permissions for allowing users to add Tags and Categories to an article.
• Hidden: Tags should be hidden from Extension:CategoryTree. Tags should not be listed in any Special page, Transclude, or MagicWord that lists Categories.

I've built a topic-tagging system, for inline tags, with some nice features like anchors, descriptions, tag-list, and highlighting. Extension:TopicTags

You can view a demo here.

At the bottom of the page for the Muffin proxy, there is a link to the edible muffin in the related pages.

Hi. Short articles like this are very challenging for an algorithm, but a proposed change to our algorithm might make a difference: Extension:RelatedArticles/CirrusSearchComparison#Hollywood Library

But no matter what we do, algorithms will occasionally get things wrong, as we so often find with search. Here is a solution that should address the most egregious examples:

Editors can change the suggested articles given by adding up to 3 manually curated examples to this part of the page navigation.

{{#related:new page title1}}

{{#related:new page title2}}

{{#related:new page title3}}

For example, on https://en.wikipedia.org/wiki/Korur_language the related pages have been over-ridden to:

{{#related:Western Oceanic languages}}

{{#related: New Guinea}}

{{#related: Mbula language}}

Let me know if you continue to have trouble.

inanın hiç bir şey anlamadım ben sesli sohbet sayfasına bakayım dedim ama sayfada hep saçma birşeyler mevcut

In my opinion it would be more appealing to have the Related Pages above the sources section, or somewhere in between the paragraphs, so its more available and visible, rather than hiding it at the very bottom of the page.

Putting between two sections is much more difficult than just at the end of the page and also can cause errors (e.g. what to do if there is not exactly one such section or it's just somewhere in the middle of the article). Localization is also more difficult as the software needs to know all possible section titles.

I love hovercards and would like to see the feature implemented for related pages as well.

Hi @MammothManni, can you please elaborate a bit on that? You mean you would like related pages cards to resemble those of hovercards?

Sorry if I was not clear. I would like to see a hovercard open up if I hover over the suggested related page card that is shown underneath the article. I.e. a short preview of the related page should open up, the same short preview that also pops up if you hover over a link within an article and have the beta-feature "hovercards" activated.

I see what you mean now. Basically making the cards more brief and hoverable. This is a design decision @Npangarkar (WMF) that requires research I guess.

Basically I want more information about the related page before clicking on it. You could make the card bigger and integrate more info already. Or, and that was my suggestion, just make a small window pop up with more information when you hover over the card.

@MammothManni Hey, this sounds like a good idea, we can expand the related pages card on hover. the bigger issue is we are still figuring out the value of related pages on desktop. you mentioned hovercards, so I'm assuming you are talking wikipedia on desktop (Vector) there have been discussions about removing related pages feature from Vector. @Melamrawy (WMF) can we look into the progress of consultation around that?

@Npangarkar (WMF) Yes, I am using Vector and only talking about the desktop version.

The article en:Hard disk drive gives en:Seagate Technology as a suggestion, but not any of its competitors. This is undesirable.

@Ruud Koot if it's based on calculated similarity rather than editor bias, is it still an NPOV violation? It is not favoritism...if these were authors, I don't think we would feel the same way.

Yes, because everything about the presentation of these results tries to make the picks look like an objective selection instead of a number of best-effort search results (most notably them being displayed without a request from the reader, close to other hand-picked navigational content). This would be very different if these results were just the top results on several pages of search results, displayed after a user-initiated query. Context, presentation, and user expectation matters.

When the algorithms selects, say, classic authors this may not always be harmful, but when it starts picking commercial companies or political parties it certainly is. See also Search engine manipulation effect.

Okay, thanks for the additional context.

Please check the moving to stable plan and proposal here. Thanks