Only send notifications that match user language setting

I have similar problem. When user A submits some content when viewing site in language X chosen in the language switcher, the notification is delivered to user B in language X no matter what the preferred language of user B. Any solutions would be great!

To be considered for 4.x branch.

Same problem here. Plus, the current language that works fine with authenticated lan is not supported at all for anonymous users, falling back to site default (probably via user_preferred_language($account)) without setting current language into {notification} table (i.e. via language prefix).

In that case, even if notification will be submitted only for current language, mechanism will fail for anonymous users, since default language is used instead of the language of the page where the anonymous user subscribes.

Imo, a correct implementation should:

• Harmonize anonymous and authenticated language detection (the first based on page language via global $language instead of site default, the second correctly reading $account->language).
• Checking anonymous and authenticated language before send a notification, using $node->language.

I try to look for a solution, but code seems too much wide and complicated for me. Changing get_language() logic into include/notifications_subscription.class.inc has no effect on {notification} table for anonymous users.

        // The setting above works fine with $account->uid > 0. 
        $this->_language = user_preferred_language($this->get_account());
        // Below I try to force current language, without success.
        global $language;
        $this->_language = $language;

If this feature will be implemented, a language policy setting could be useful in notification administration interface, something like:

Language policy:

[ ] Send only notifications for content written in current user language
[ ] Send notifications for all languages (it could send multiple email for translated contents)

Anonymous notifications language policy:

[ ] Current content language with default language fallback
[ ] Default language only

It's only an idea to explain language settings and open to further developement on language integration, that now is the weaker point of this very useful module.

Any idea how to implement these features?

subscribe

i had duplicated this.. ooops.. will close that one.. and subscribing here.

going through code i see a few comments from Jose stating @todo for this... in 4-dev branch so far i have found/fixed (some) bugs in:

anonymous, custom, cck, and core notifications modules.. trying to fix all of them this week. and trying to add issues where i can but some of the bugs are simply obvious (like typos and missing args in switch statements, etc) - not sure i'll create separate issues for each of these and some i dont even know what the issue will be that they are causing.. but clearly are bugs...

looking at this now and minor comment on #3 above:

Checking anonymous and authenticated language before send a notification, using $node->language.

i think should be "before queuing a notification" - important distinction.

part of my observations on this so far:

test case:
- 2 users, one EN and one FR (havent started looking at anon issues yet, that's next)
- edit an EN node (which is synced to a FR node so it updates as well)
- i get 2 Events created - one for the EN node and one for the FR node (this is good)
- i get 4 items queued (this is bad - the main issue reported here)

to note: the 2 Events are both tagged with EN, not sure where that fits into things just yet; but seems likely wrong.

this is not likely generic enough solution but seems to be working for my test case, which is above.. plus,

my subscriptions are Custom Notifications based on taxonomy and node type (have only tested node type so far; but expect tax and type to work the same).

i have not modified any of the Notifications code (although it should be fixed), but i simply did this in an external module:

function cta_notifications_query_alter(&$query, $event) {
  $query['where'][] = "s.language = '%s'"; 
  $query['where args'][] = $event->objects['node']->language;
}

this basically modifies query select to it does not include items which do not match the subscriptions language (i.e. the language in the notifications table, i.e. the subscribers preferred lang).

this is using the drupal_alter that is provided in queue_event(), but could likely be added above as code above the alter to patch this module so people dont need to do the alter code in a separate module.

sub

I'm using 6.x-2.3 & I have this issue too with a dual-language site.

@liquidcms I'd be interested in knowing more how to apply your solution. Where in the notifications module would I need to insert the code? (Or if not possible, how would I create an external module?)

I'd say this is more the nature of a bug rather than a feature request, but I'd haven't changed it. Getting the language right is pretty important.