Bundled notifications shouldn't be counted in the badge -- that is, the badge should recognize it has an extra (+1) notification that is the cross-wiki one, but it shouldn't display the number of sub-notifications that that bundle holds.

For example, if I have 10 unread notifications locally, and a bundle with 5 unread from wiki1, 2 unread from wiki2, and 1 unread from wiki3, the badge should have the number 11, and not 19.

What we do have as a bug here is that the nojs-version produced by the backend *does* count the sub-notifications, which is inconsistent with the frontend JS ui which doesn't, which is why the badge doesn't represent the number correctly when the page just loads AND why the badge number changes when you open the popup (because it's replaced by the JS version)

I personally think we should stick with the way the UI works (counting cross-wiki as *one* notifications) but either way, since the backend and frontend behave differently, we should make a decision and then make sure both act the same.

@Catrope, @jmatazzoni, @Pginer-WMF -- your input is welcome.

For example, if I have 10 unread notifications locally, and a bundle with 5 unread from wiki1, 2 unread from wiki2, and 1 unread from wiki3, the badge should have the number 11, and not 19.

The cross-wiki bundle is just a group of notifications, I don't think we should count it as one.
I think there are two ways of counting that can meet the use expectations:

• Count all notifications. If we consider that the panel now gives us access to notifications from all sites, we can assume the counter indicates all the pending notifications, regardless of their origin. In your example, the counter would be 19.
• Count only local notifications. In your example, the counter would be 10. The problem with this is that getting new notifications on other wikis may result in a highlighted "0" badge, which may be confusing (keeping it as "1" has similar problems).

Since the goal of cross-wiki notifications is to give more visibility to what is going on elsewhere, I'm more inclined to go with the first approach and keep the count global and consistent on all wikis. In theory, having a global counter can lead to higher numbers (making them less relevant), but we need to check how often users end up with lots of unread notifications from different wikis (and how different would be to count them separately in that case).

It's clear that the behavior of x-wiki notifications puts them in a somewhat ambiguous status. These messages both are and, in some ways, are not "in" the current panel. So I could see this going (and us getting complaints) either way.

However, for many of the same reasons Pau sites above, I'm inclined to say that the counter should count everything that is in the panel, including notifications from other wikis. I think that behavior will be more clear and consistent -- though, as I say, I fully expect there will be some who would not wish it.

I see a couple of minor issues here:

• Occasionally, a small number of people will see "99" as their number when they actually have more messages. 99 is, if I have this right, the highest number the badges are able to show. Would we want to increase the limit to 999? If we did, would the design accommodate it?
• I foresee that some people may wish to turn off x-wiki in some wikis. This would probably be the case whatever the numbering, but the numbering may make it more pressing. Since that behavior is more or less possible now via the beta opt-in, tracking the need for it during beta will be difficult....

Occasionally, a small number of people will see "99" as their number when they actually have more messages. 99 is, if I have this right, the highest number the badges are able to show. Would we want to increase the limit to 999? If we did, would the design accommodate it?

It makes sense to avoid stating "99" translations when you have more than that. However, I'm not sure the precision past that point matters much (i.e, having 99 or 123 pending notifications is just "a lot"). I'd propose the counter to be "99+" once the user has more than 99 notifications.

According to our recent data about notifications, there are 12 users with more than 100 alerts, and 43 users with more than 100 messages (curiously, the numbers are much higher for those having exactly 100)

I foresee that some people may wish to turn off x-wiki in some wikis. This would probably be the case whatever the numbering, but the numbering may make it more pressing. Since that behavior is more or less possible now via the beta opt-in, tracking the need for it during beta will be difficult....

That is a valid concern. However, I think beta-features will still be helpful: if a user enables the feature to notice that (a) it is useful to view notifications from other sites, but (b) the counter went up so much that is distracting, we will easily hear about the later. Research with users making use of the feature on their real notifications will be helpful to surface these issues.

Also, based on the previous data, most users don't seem to have pending notifications from many different wikis at a time. Thus, the total number of notifications may not be much higher than the one of their busiest wiki.

I like the idea of 99+ as well. Thanks Pau.

Do we have a decision that 1) all notifications should be counted and 2) the counter will stop at 99+?

Yes, let's go with that decision.

Change 271690 had a related patch set uploaded (by Sbisson):
[WIP] Include cross-wiki notifications in unread count

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

Change 271690 merged by jenkins-bot:
Include cross-wiki notifications in unread count

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

Checked the fix in betalabs (for both scenarios)

• all unread messages are counted; refreshing does not return the count to the previous count (checked the first scenario)
• deleting some of the bundled notifications is reflected immediately and correctly in the counter
• turning 'Enhanced notifications' beta feature ON/OFF does not cause the counter to make mistakes.

Closing this bug. However, Elena is going to find a way to try out the 99+ feature and will reopen if that's a problem.