It sounds like there are a few different topics here:

• The notification should provide an indication it goes off-wiki
  • Are there any other notifications which go off-wiki? I'm wondering if there are any designs we should be matching.
• The notification isn't being marked as read after clicking
  • We just tested this and confirm this is accurate.
• We should discuss moving TWL into production
  • Could you elaborate on what this means, practically? i.e. what environment(s) are you referring to?

In T295621#7506368, @Samwalton9 wrote:

It sounds like there are a few different topics here:

• The notification should provide an indication it goes off-wiki

This is the main issue IMO.

• The notification isn't being marked as read after clicking (is this accurate? Does it never mark as read when being clicked?)

Correct. You have to mark it as read manually.

• We should discuss moving TWL into production

This would take care of the privacy aspect but not fix the markasread behavior.

In terms of the off-wiki part, are there any other notifications which go off-wiki? I'm wondering if there are any designs we should be matching.

I'm not aware of any and IMO I don't think it's something that should be encouraged nor standardized either.

I'm really glad @Legoktm mentioned the Interwiki map, as I think it looks like best way to handle this. We already have a special view on our platform for linked searches, and with a very small adjustment it could also handle this case very nicely.

I spent a few hours experimenting with customizing the secondary link, and here's what I found:

• Adding the external link icon to a secondary url requires adding oojs-ui.styles.icons-editing-core to the dependencies of echo itself. I think we probably don't want to go that route since external links in notifications are a bit of an abberation
• It also leads to an odd situation where we have two very similar calls to action. Rewording would mean another round of localization
• We could choose to not have a primary link at all, but again we would need to reword the main message
• Setting the url on the primary link to an empty string would cause it to link to the notifications page, which would respect the mark as read parameters, but would again require rewording and also testing for how this appears in email

I want to check in and make sure the interwiki map is an acceptable solution for @Samwalton9 before I proceed.

In T295621#7514639, @jsn.sherman wrote:

I spent a few hours experimenting with customizing the secondary link, and here's what I found:

• Adding the external link icon to a secondary url requires adding oojs-ui.styles.icons-editing-core to the dependencies of echo itself. I think we probably don't want to go that route since external links in notifications are a bit of an abberation

Is this a problem for adding any new icon to the notification, or that icon specifically? I'm wondering if we can find something similar, if that would avoid this problem.

• It also leads to an odd situation where we have two very similar calls to action. Rewording would mean another round of localization
• We could choose to not have a primary link at all, but again we would need to reword the main message
• Setting the url on the primary link to an empty string would cause it to link to the notifications page, which would respect the mark as read parameters, but would again require rewording and also testing for how this appears in email

I see the concern here. What if we instead went back to something like our original idea, where the secondary link text is "The Wikipedia Library" and it points to https://meta.wikimedia.org/wiki/The_Wikipedia_Library?

I want to check in and make sure the interwiki map is an acceptable solution for @Samwalton9 before I proceed.

With respect to denoting that the link goes off-wiki, would using an interwiki map resolve your concerns @Legoktm? It strikes me that if this is a simple redirect then the effect is largely the same - users are still taken off-wiki they just get there via an on-wiki redirect - in which case that might still be necessary. The notification would be marked as read correctly but I don't know that this solves the off-wiki link issue.

Is this a problem for adding any new icon to the notification, or that icon specifically? I'm wondering if we can find something similar, if that would avoid this problem.

This is a really good question, and the answer is ... complicated. We can add one icon of our own, which we have done for the primary book icon. If we wanted to switch to a standard icon as the primary, I think we could add our own for the secondary. I haven't tested that yet, though.

Otherwise we can choose from the following oojs ui icon sets, which are already dependencies
user, alerts, content, interactions, moderation, movement
You can browse through all the sets here here:
https://commons.wikimedia.org/wiki/OOUI_icons

We can also use the icons provided by echo itself:
https://commons.wikimedia.org/wiki/Category:Notifications_extension_icons

It strikes me that if this is a simple redirect then the effect is largely the same - users are still taken off-wiki they just get there via an on-wiki redirect ...

I know this isn't addressed to me, but I thought I could add some context while I'm here. The interwiki redirects provides an interstitial dialog letting the user know they are going off wiki:

Realized I didn't answer one of your questions:

I see the concern here. What if we instead went back to something like our original idea, where the secondary link text is "The Wikipedia Library" and it points to https://meta.wikimedia.org/wiki/The_Wikipedia_Library?

That would resolve the call to action issue. We'd still need to allow for localization time if we want that translated since the message string will change. If the user clicked the primary link to the library, we would still have the mark as read issue. If they clicked the secondary link, the message would be marked as read.

If we wanted to switch to a standard icon as the primary, I think we could add our own for the secondary. I haven't tested that yet, though.
...
We can also use the icons provided by echo itself:
https://commons.wikimedia.org/wiki/Category:Notifications_extension_icons

I've tested this now, and for primary icons, this is actually what we get for primary icons if we aren't adding our own.
https://github.com/wikimedia/mediawiki-extensions-Echo/tree/wmf/1.38.0-wmf.9/modules/icons

We can't add our own local icons for secondary links. The icons have to be from the included ooui icons, or the icons available for primary links

I see the concern here. What if we instead went back to something like our original idea, where the secondary link text is "The Wikipedia Library" and it points to https://meta.wikimedia.org/wiki/The_Wikipedia_Library?

That would resolve the call to action issue. We'd still need to allow for localization time if we want that translated since the message string will change.

Judging by other notifications the precedent seems to be that if you're linking to a page, https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_article-ltr.svg is the icon to denote that.

I'm not super fussed about "The Wikipedia Library" being translated before this goes out further - it's a kind of 'brand name' and the important message is the rest of the text, which is already fairly widely translated.

Let's go ahead with this for that piece of the notification. I'll update the task description for this piece.

The interwiki redirects provides an interstitial dialog letting the user know they are going off wiki:

Oh that's helpful! Is that always the case or do you need to link to a particular page? A wikilink to [[google:foo]] sends you straight on without the dialog. See https://meta.wikimedia.org/wiki/User:Samwalton9_(WMF)/sandbox.

Yep, we would use something like:
https://meta.wikimedia.org/wiki/Special:GoToInterwiki/google:foo

Great - the scope of this task has been changed to focus on the secondary link update. Filing another task for the interwiki map.

Okay, so is this what you're thinking?

I'll need to figure out how to grab the email from within vagrant to see what it looks like there. Or we could decide to drop the emails as part of this change too.

Okay, so is this what you're thinking?

Ideal!

I'll need to figure out how to grab the email from within vagrant to see what it looks like there. Or we could decide to drop the emails as part of this change too.

That sounds sensible, let's bundle the changes and make this a no-email notification.

I asked around and 5/5 editors with opinions on this thought it should be on-wiki only. Additionally, editors receive the notification right after making an edit, so they are likely to be actively editing and seeing it directly anyway - it's not a particularly useful asynchronous notification.

When you're dropping the email part can you confirm that 'View the library' is only used in the email and remove that too?

Patch inbound. I was able to drop that primary link label, and everything looks happy. I tested in a few languages, and localization still works as expected.

Change 740204 had a related patch set uploaded (by Jsn.sherman; author: Jsn.sherman):

[mediawiki/extensions/TheWikipediaLibrary@master] Add a secondary link to the notification

https://gerrit.wikimedia.org/r/740204

Change 740204 merged by jenkins-bot:

[mediawiki/extensions/TheWikipediaLibrary@master] Add a secondary link to the notification

https://gerrit.wikimedia.org/r/740204