Email notifications

[remkus]

I'm aware that there's already an issue related to notifications, but I'd like to approach this feature a bit more complete.

I propose we implement an email notification feature that sends out a notification based on a couple of different scenarios.

What kind of notifications

1. New strings added. This is the most obvious one and is all about when a new .pot file gets imported into a project.
2. Strings ready to validate. This scenario is about when users have submitted translation suggestions. The email should contain a link to the to be validated/translated text strings per project.
3. Strings have been marked as Fuzzy. This is related to the first item here as strings only get marked fuzzy when new .pot file get imported. The email should contain a link to the fuzzy text strings per project.
4. When a project's translation percentage is below a predefined threshold. User should be able to define a minimum percentage per translation project. When the translation get's below a set percentage, based on the changed amount of text strings left to translate, the user should get a notification that there are text strings to be translated. The email should contain a link to the untranslated text strings per project.

Bundling content in emails

If multiple conditions across one or more translation projects are met, they should be bundled into one email.

Email content

Ideally, I'd like to see an email notification system like BuddyPress has implemented where you can easily override the default texts.

User settings

In order to make this feature as versatile as possible, we're going to need a couple of user-defined settings.

Opt-in

A user should be able to define whether he wants to receive emails or not.

Email frequency

A user should be able to define at what interval they would like to receive the emails. I think the following settings should be sufficient.

• immediately (in bulk still)
• hourly
• daily
• weekly
• biweekly
• on which day

Project Translation Minimum Percentage

A user should be able to set a minimum percentage a translation has to be per project. If the percentage gets below the set value, the email should be triggered.

[tacoverdo]

First iteration

This comment is a first iteration based on a Yoast Contributor Day session we, @noud-github, @arjanvandenelzen, @remkus & @tacoverdo, had on the validity of all the various items in our initial wishlist.

We've concluded that in keeping true to the core of the proposal, we have to pick a solution that is easy to implement, scales and performs well in large-scale environments.

Non-technical summary

Our goal is to propose the first iteration of a solution for this feature. This proposal is aiming to describe a minimum viable solution that would introduce this functionality and is open to further iterations.

When implemented, a user will be able to sign up for email notifications for a specific language in a specific project. A contributor can do this by subscribing to that language through a button on the language’s page.

Our proposal

The user interface for subscribing and unsubscribing

We suggest adding a subscribe (or unsubscribe) button to the page on which translators can enter their translations.

Example URL: http://mysite.local/glotpress/projects/tp/nl/default/

We chose this location for (un)subscribing because this page already exists, and the project is aware of the locale and the user. Therefore this is the most pragmatic location. Also, from a user perspective, it makes sense to sign up for notifications here as one would be on this page to translate this specific project into their language.

Scalability

The issue lists a summary of wishlist items we'd like to see in an ideal world. In our discussion, we quickly discovered that the scale of more than 50K plugins times more than 1M users. Iterating through all of these records per user would be too resource costly.

We have identified multiple solutions to store one’s subscription to a project/language. The two solutions that would have an acceptable impact on performance and scalability are adding an extra table to store meta-information for translation sets, e.g. _gp_translation_sets_meta the other one is adding the project and language to the user_meta.

We expect the latter solution to have a significantly larger impact on performance and scalability, as it would require GlotPress to iterate over all users to find the users subscribed to a specific locale of a translation project. Also, by adding additional information to the user meta, other queries touching the user meta may be affected too.

The first solution, adding an extra table for translation set meta, would allow saving the user IDs per translation set. The reason we feel this is the better solution as it allows for less complex queries. It also doesn’t affect the user meta, thus not affecting other queries in WordPress (core).

Sending notifications

The trigger for the action of sending the notification email would be when a new .pot file is imported into a translation project. Upon importing, as one of the last steps in the import process, we need to look up the set of users to send the below-mentioned mail to.

Example email in pseudo code

Subject: "<site name>:New strings available for <project name>"

Hello <firstname>,

There is an update for the <translation project> project:

If new text strings {
The <translation project> project saw X-amount of new strings. <Link>
}
If deleted strings {
	The <translation project> project saw X-amount of strings deleted. <Link>
}
If fuzzied strings {
	The <translation project> project saw X-amount of strings fuzzied. <Link>
}

Best regards,
 <site admin>

You are receiving this message because you subscribed to text string updates for <translation project> Unsubscribe here.

Possible future iterations

• List all subscriptions in the user profile
• Move to subscribe to projects to user profile
• Add scheduled mail
• Add filter to disable this feature
• Add option to delay sending updates (e.g. daily or weekly summary)

[toolstack]

We might want to hold off on this for a bit as the WP Notify working group has kicked off and we'll likely want to tie in to that for the actual mechanics of sending notifications.

[pedro-mendonca]

Also, there were some ideas kicked off in WordCamp Europe Contributor Day about connecting GlotPress with bbPress precisely to use its forum notification and discussion features.
Maybe @ocean90 and can share how it developed.

[remkus]

@toolstack @pedro-mendonca, I'm afraid waiting for both of your mentioned projects to be concluded, we'd be a long way in the future. I see no problem in coding up the solution for this issue taking into account that certain parts can be integrated later. The logic, the UI, and where to save what and contents of the email would be the same regardless of whatever code the notification can hook into.

In other words, let's not make this a future milestone, but one that is built now(-ish) and kept flexible enough to merge into whatever may come.