| Nikerabbit | |
| Oct 10 2023, 7:53 AM |
| F42752205: image.png | |
| Mar 19 2024, 2:05 PM |
| F42751623: image.png | |
| Mar 19 2024, 1:33 PM |
| F42751229: image.png | |
| Mar 19 2024, 1:12 PM |
| F42751215: image.png | |
| Mar 19 2024, 1:11 PM |
Open questions:
Expecting to have:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T351374 Improve Translatable Pages based on research input | |||
| Open | None | T348500 Allow translators to watch message groups | |||
| In Progress | abi_ | T348501 Minimal prototype implementation for watching message groups | |||
| Open | None | T363663 Add a page where translators can see a list of all groups that they are subscribed to |
The version 0.1 for this feature, we are planning to notify watchers when a message is added or removed from a group that they are tracking via Echo notification. The feature will initially be enabled on translatewiki.net.
Table name: translate_message_group_subscriptions
Columns:
Primary key: Composite primary key: tmgs_group, tmgs_user_id
We will add a new MessageGroupSubscriptionService that will provide the following functionality:
All or most of these functionalities will be available via an API that the front end will interface.
The MessageIndex can be used to determine if a new message has been added under a group. When this happens, one job per group can be dropped in the queue that has information about all the messages that were added or removed.
What will this be used for? I see little value in being able to know when the user subscribed to the given group. The watchlist table doesn’t store either the date when the user added the page to the watchlist (the wl_notificationtimestamp column stores something else, and it’s necessary for the “updated since your last visit” markers and the notification emails to work).
- Remove all subscriptions for a group
- To be used when a group is deleted
I hope a notification will be sent if a subscribed group is deleted, won’t it?
I have updated the title to better match the updated scope for this task. The front-end/back-end split wasn't the best way to split it.
The goal is just to create minimum implementation so that we can store subscriptions, manipulate them manually using the service and send a notification (preferably automatically, but manually triggered is okay too).
On top of this we can build an UI and more features in further tasks based on designs and user feedback.
Change 986865 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] Add table to store user message group subscriptions
Change 986866 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] Tux: Display button to subscribe to message group
Change 986867 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] Add API to allow users to subscribe to message groups
Change 986868 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] Tux: Allow users to unsubscribe from message groups
Change 991475 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] Add TranslateEnableMessageGroupSubscription configuration
Change 991530 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] Do not allow users to watch dynamic message groups
Change 991737 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] Create base to send notifications when messages are added / removed
Change 1007472 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] WIP: Add echo notification for message group subscription
I'm wondering how best to structure the notifications sent to the user.
Currently the plan is to send each user subscribed to a message group, a notification whenever a change is made to the message group.
The problem with this approach is that this might result in large volume of notifications to be sent out. For example, when translatewiki imports messages from repositories, there might be multiple message groups that may have changes. If a user is subscribed to one or more of these groups they would get one notification for each group that's been updated.
I'm thinking of mitigating this problem by looking at bundling the notifications as described here: T114356: Notifications panel: Easily explore bundled notifications
Following this scenario the notification message would look something like this:
OpenStreetMaps was updated: 3 new messages, 0 old messages.
Clicking on the notification would redirect the user to Special:Translate with OpenStreetMaps selected.
An alternate approach would be to send one notification to the user for all the groups that they are subscribed to.
This notification message in this case would look something like this:
The messages in the following projects were updated: OpenStreetMaps, Kiwix and Wikidata Locator.
Clicking on this could redirect the user to Special:Translate with Recent additions selected.
The drawback of this approach is that finer details are lost.
I'm leaning towards the first approach including the bundling of the notifications so that it's not too noisy.
I would also lean on notification bundling (or deduplication) as the preferred approach. I would also suggest to start just with "Group XYZ has new things to translate" without bundling or additional info to get this feature out for testing and do the improvements as follow-ups.
A drawback of bundling is that it doesn’t happen when the notifications are delivered by email. It’s not necessarily a bad thing to get separate emails about separate groups, though (it can help e.g. if one uses emails as a todo list or uses filters to put mails about different message groups in different folders).
Change 1011445 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] MessageGroupSubscription: Add logging
Users can watch message groups. In the first release of this feature, user will receive notifications whenever there are new or deleted messages in the message groups that they are watching.
Change #1007472 abandoned by Abijeet Patro:
[mediawiki/extensions/Translate@master] Add Echo notification to be sent on messages addition or removal
Reason:
Squashed with I7a9246dce8fe8386abac8b7840a546627957c639
Change #986865 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Add table to store user message group subscriptions
Change #986866 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Tux: Display button to subscribe to message group
Change #986867 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Add API to allow users to subscribe to message groups
Change #986868 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Tux: Allow users to unsubscribe from message groups
Change #991475 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Add TranslateEnableMessageGroupSubscription configuration
Change #991530 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Do not allow users to watch dynamic message groups
Change #1021508 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[translatewiki@master] Enable message group subscriptions
Change #991737 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Send notification for message groups when a message is added/removed
Change #1011445 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] MessageGroupSubscription: Add logging
Change #1021508 merged by jenkins-bot:
[translatewiki@master] Enable message group subscriptions
The feature is enabled on translatewiki.net to gather feedback. Feedback can be provided here, or on the support page on translatewiki.net
Leaving this task open for a couple of more days to gather feedback or to report any issues that users might find.