@Jhernandez The lists of allowed wikis for the Chrome/FF ext. and the Safari ext. have the details of projects you could try.

In T197822#4494243, @Jhernandez wrote:

Would it be useful if the apps behaved better with those pages? In the case of opening an entry that they don't know how to handle, they could open a browser window like they do on other places, so that would make the pages more functional (for example the flow board). That way the experience is not broken and users have a bit more flexibility on what to add to the lists.

I would consider "opening in the browser any links that the app doesn't support" - an easy solution that would possibly be difficult to the end-user. I say that way because, this plugin is being advertised as "Wikipedia reading list plugin. Generally, I would expect that I can read the page that I add to reading list using the plugin in the app. Also given that the app (at least the android one) stores the pages on the reading list offline (for offline consumption), I would expect that I could read every page I add to the list when I'm offline. If the plugin is flexible thus allowing it's users to add any allowed Wikimedia wiki page, I would be frustrated to see most of the pages that app doesn't support to open in the browser as I wanted read it when I'm offline. For example, Wikimedia Foundation Guiding Principles. I can add that page to my reading list (via the plugin) but cannot read it in the app. To add to my frustration the app never complains it could not download that page for offline consumption when it syncs the reading list pages. It just fails silently and I see a "This page does not exist" error when I open it later (possibly when I'm offline).

Also, for the non-Wikipedia pages that the app could open, it should change the footer accordingly. This should help users identify the source wiki and the corresponding content license correctly and help tge attribute properly (rather attributing content found in wikis like Wikimedia Commons to Wikipedia).

Re: adding pages from non wikimedia wikis, is that possible? Which wikis did you add User:Kaartic from to your lists? How did you add them? (browser extension?)

I'm trying to get a sense of the wikis that should be available and if the issue is with the browser extension, or the apps, or the API layer.

First to be precise I added pages from non-Wikipedia wikis not from non-Wikimedia ones. I did add them using the plugin. I don't remember the actual set of Wikis but you could try en.wikipedia and meta.

And, this is my view of the problem, of course :-).

Thanks for the input @Kaartic, very useful.

I personally like that we can add pages from the different wikimedia wikis to the lists, but it is true that the only platforms that expose the lists (apps) don't react very well to those entries in the UI, thus creating confusion for users of the browser extensions.

We could do any of these:

• Update the browser extensions to only expose the functionality on the projects and types of pages that the apps support gracefully

Or

• Leave the extension as is and create bugs for the apps to handle pages from other projects or types of pages more gracefully
  • This would involve show some sort of domain/project-code on the UI on the lists for pages with the same title
  • And also handling better opening pages that are not main namespace content, by using a browser when online, and a nice message about that page not being available while offline for the other ones like special pages, etc.

Ping @Mholloway who worked on implementation: Do you remember where the list of domains and projects and types of pages allowed came from? Should we constrain the extensions or push for the apps to be resilient to the behavior that the extensions expose?

I guess the best solution would be to disallow users of the plugin from adding pages that the apps can't handle well until they fix it. That might prevent bad experience in the apps but might degrade the user experience of the plugin.

I guess this is one of those times where the inconsitency between the apps and the web is causing complexities :-(

In T197822#4510145, @Jhernandez wrote:

Ping @Mholloway who worked on implementation: Do you remember where the list of domains and projects and types of pages allowed came from? Should we constrain the extensions or push for the apps to be resilient to the behavior that the extensions expose?

The easiest thing to do would be to constrain the extensions. That would be as simple as removing all project hosts but 'wikipedia.org' from the lists @bearND linked above (T197822#4494522) and then going through the modest administrative hassle of publishing updates.

Another option would be for the apps to filter out non-Wikipedia pages and other undesired pages on the client side, and display only app-handled pages to the user. I imagine that if/when reading lists make it to the web site(s) proper, they will not be constrained to the Wikipedias only, so this might be the more future-proof approach.

In T197822#4549172, @Mholloway wrote:

The easiest thing to do would be to constrain the extensions. That would be as simple as removing all project hosts but 'wikipedia.org' from the lists @bearND linked above (T197822#4494522) and then going through the modest administrative hassle of publishing updates.

Actually, we'd need to add a namespace whitelist or something along those lines as well. This sounds easy in principle but might actually end up being tricky due to namespace localization and aliasing.

In any case, as I mentioned earlier, I think reading lists are going to be non-Wikipedia-specific in the long run, so what we do here should probably be informed by product thinking about what do to about that in the apps.

My vote goes for removing all sites except WP and wikivoyage.

One of the reasons why it doesn't work on most sites in the Android app is that recently RESTBase storage for the mobile-sections endpoint has been turned off for non-WP sites. A couple of weeks ago it has been turned back on for wikivoyage. So, this site should work to the point where it can actually show the page content, which I think is a nice but unofficial feature when travelling and being offline. Granted the links don't work/open in a browser and the footer incorrectly claims it's Wikipedia. But I think it's good enough for an offline experience when travelling.

We definitely should not allow Special pages to be added to a reading list. Maybe just leave main ns + Project ns? You could probably use wgCanonicalNamespace ('' or 'Project') or wgNamespaceNumber (0 and 4) to determine the namespace.

https://github.com/wikimedia/webextension-readinglists/pull/12 and https://github.com/wikimedia/readinglists-extension-safari/pull/8 to limit handled projects to Wikipedia and Wikivoyage are merged. Still need to check the namespace.

I've got patches ready to go that filter out pages in NS_SPECIAL while avoiding the need to get into passing messages with the DOM. If just filtering special pages (which are the focus in this task) is sufficient, I'll push for review.

If we want to go further and filter multiple namespaces based on a blacklist or whitelist, it'll require adding a content script for FF/Chrome and some similar mechanism for Safari and checking against wgNamespaceNumber.

In T197822#4605382, @Mholloway wrote:

If just filtering special pages (which are the focus in this task) is sufficient,

I never thought that was the case. IMHO, it shouldn't bbe possible to add any page that doesn't work well in the app via the plugin. Special: pages are just an example. Talk: pages with flow boards are another example. It would be nice if the pages that don't work could be identified. I'm not sure there's an easy way to identify them.

If we want to go further and filter multiple namespaces based on a blacklist or whitelist, it'll require adding a content script for FF/Chrome and some similar mechanism for Safari and checking against wgNamespaceNumber.

I guess filtering namespaces would be better than just avoiding Special: pages. I'm not sure which namespaces work well, though. Just allowing the Main and Project namespace sems too constraining as the other namespaces like Wikipedia: are rendered well too. Old-style Talk: pages are rendered well too.

Published v1.1 for Firefox and Chrome, which limits the active sites to Wikipedia and Wikivoyage, and limits the active pages to articles in the main namespace. Approved namespaces can be refined further in future versions.

The Safari extension update is submitted and awaiting approval.

Updated Safari extension is approved and should be live in the Extensions Gallery. I'll leave the task open for possible future refinement work.