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

• https://en.wikipedia.org/wiki/Revolution_Muslim and https://en.wikipedia.org/wiki/Chesser give https://en.wikipedia.org/wiki/Chess as a suggestion.
• https://en.wikipedia.org/wiki/Time_%28disambiguation%29 gives https://en.wikipedia.org/wiki/Stargate, https://en.wikipedia.org/wiki/Stargate_SG-1 and https://en.wikipedia.org/wiki/Atlantis:_The_Lost_Empire as suggestions.
• https://en.wikipedia.org/wiki/List_of_serial_killers_before_1900 gives https://en.wikipedia.org/wiki/Peru_national_football_team as a suggestion.
• https://en.wikipedia.org/wiki/Murder_of_Kelly_Anne_Bates and https://en.wikipedia.org/wiki/Holocaust_%28disambiguation%29 suggest https://en.wikipedia.org/wiki/Batman.
• https://en.wikipedia.org/wiki/Korur_language suggest Anus, Anal and Poop.

I don't think these would be editorial decisions we'd ever make.

That kind of problems could be easily fixed in a wiki.

@Ruud Koot@Kusma Wow. Some of these are really bad--thank you for calling them to our attention. As @Jdlrobson mentioned in another thread, the algorithm isn't so hot on disambiguation pages in particular. Perhaps we will want to disable it on those pages, as it is not helpful there anyway.

As to the others, as with any search results, sometimes the machine generated results require curation.

This is one reason that editors can override the suggestions using the #related keyword, like so:

{{#related:new page title1}}{{#related:new page title2}}{{#related:new page title3}}

They won't be fixed, most of them. Curating an additional potential problem in 40 million articles is far beyond the communities' capabilities, and wouldn't be a good use of resources even if it wasn't.

Well it's worth noting a lot of this work has been done already in "See also". I'm interested in how we might consolidate these features as doing so would allow more granular access to our data e.g. allowing our consumers to use the API to give me the pages listed in see also for article X

Monolithic chunks of wikitext obviously don't lend well to this kind of use case.

Do you mean by "[m]onolithic chunks of wikitext obviously don't lend well to this kind of use case", that the 'See also' section should not be stored as plain wikitext? This may seem like a good idea at first (because a few rows in a database are much easier to query than having to parse arbitrary wikitext), but opens a rather large can of worms:

• How should the 'See also' section be edited?
• How are you going to deal with articles that have, for good reasons, unusually formatted 'See also' sections?
• Which 'See also' section do you display if a user views an older revision of the article?
• How do you display combined changes to the article and the 'See also' section if an editors view the diff between an old and a new revision?
• How are you going to integrate the change log of the 'See also' section with the history page of the article, the Recent Changes log and people's watchlists?
• What happens to the 'See also' section if an article gets deleted and later undeleted? (In the case of interwiki links, which were all moved to Wikidata, it turned out that they do not get restored properly on undeleted. Fixing this bug turns out to be extremely difficult/"not worth the effort".)
• ...

Talk to the Wikidata developers. They have been trying to fix these and many more problems for a few years now and have still not succeeded. As a result no infobox on Wikipedia is currently using Wikidata as its data source.

There are solutions to all of these and yes they vary in difficulty, maybe it's best to start with a case study.

For example, the Wikivoyage community were using templates to create banners for all pages. These templates worked great on a desktop browser but on a mobile browser worked not so well. We worked with them to setup a magic word (PAGEBANNER) that allowed them to use this instead of the template. The benefit of doing this was that various optimisations could be done before output to improve the banner for mobile (be more clever with image resolutions/allow position tweaks to the banner/ship different styles) - something their templates were not capable of. The banner information is available via the API as a side effect of this change.

In a similar fashion, given the related pages feature can be altered by using the `related` magic word, one could envision following this example and if it was desired (I'm staying completely out of whether we do this or not - I just think it's an interesting thought experiment :-)) one could envision editors using magic words/templates in some way to generate the see also section that also has this nifty side effect. (see http://en.m.wikipedia.beta.wmflabs.org/wiki/Related_test for example).