Multilingual: send notifications in language of recipient, not sender

[terraling]

It just occurred to me that on my bilingual social network (Spanish and English), all notifications from WP and BP are sent in the language of the sender, not the recipient.

Which is like, if you got a friend request on Facebook from a Polish person, the email notification would be in Polish.

I'm going to fix this on my site and was thinking it should be something that should be a core feature or at least fixable with a plug-in, but, then I realised a universal fix is currently not possible.

On my site there is an xprofile field for language preference, so I can customise the notifications to check the language preference of the recipient rather than the text simply being switched out with gettext calls based on the current user's language.

But neither BuddyPress nor WordPress store a user language preference, so a universal solution isn't possible.

Logically it's not so much a WP thing as a BP thing, so I propose that to get the ball rolling team BuddyPress as a first step nominates an xprofile field to hold the language preference. Use can then standardise around that, for the notifications, and for who knows what else down the line...

[dontdream]

I suggest that the plugin which handles the language preference lets the admin specify (in the plugin admin page, or in wp-config.php) which xprofile field contains said language preference.

This way a general fix would be available, without forcing BP to reserve xprofile fields.

[boonebgorges]

This is an interesting issue, but I don't think it's BP's place to fix it.

There is a family of plugins (WPML et al) that are devoted to serving multilingual communities with a WP/BP site. Each of them does it in its own way: some by filtering the locale and loading a different .mo file, some by doing string-by-string translation, some by encouraging different subdomains of a multisite installation for each language, etc.

Each of these solutions has different arguments in its favor for different kinds of use cases. It's not possible for BuddyPress to adjudicate which of the solutions is the "best". If the entire WP community were to coalesce around a set of best practices for the storage of user language preferences, BP would be happy to play along; but it seems out of the scope of BP alone to decide this.

As for the devotion of an xprofile field to language preferences. This does not seem like a wise idea, for a few reasons. First, the xprofile component is optional. Second, the xprofile component is generally used for publicly-displayable information, while this is more of a preference or a setting and so is probably better suited for usermeta. Third, user-specific language settings should presumably affect not only BuddyPress, but also WordPress and any other plugin; so it seems to make the most sense that they should live in a general place like usermeta. Fourth, multilingual sites make up a fairly small percentage of all BP sites, so somehow it seems wrong to reserve a portion of xprofile for a purpose that'll be moot for most sites.

As for your specific problem of notification languages, there are a number of ways that you could work around it. The most straightforward is through the use of filters. I think that all of our notifications functions run the title and content through apply_filters() before sending, so you could always filter it and rewrite it before sending to each user. Another strategy: most of our email notifications are fired on a do_action() call. Assuming that your multilingual plugin uses a filter on locale, you could hook in just before a notification is sent and filter the locale on the fly. Eg:

function bbg_friends_notification_new_request_locale( $friendship_id, $initiator_id, $friend_id ) {
    $user_locale = get_user_meta( $friend_id, 'locale', true );
    add_filter( 'locale', create_function( '', 'return "' . $user_locale . '";' ) );
}
add_action( 'friends_friendship_requested', 'bbg_friends_notification_new_request_locale', 9, 3 );

Maybe not the most elegant thing in the world, but you get the idea.

If it would help for BP to have more timely filters/actions to do this sort of thing, it'd be great to get your advice. However, in the absence of a more clearly sketched-out picture of what BP support might look like, I'm not convinced that it's appropriate for us to take a more proactive stance on multilingual implementation.

[terraling]

Thanks for the feedback. After posting this and positing that it was more a BP than a WP thing (friend requests etc.) it occurred to me that it is a problem with WP, too, e.g. in comment threads (you comment in English, a user with Spanish settings replies to you in English, but you get the notification email in Spanish).

On the one hand that seems fundamentally wrong, but on the other it's too big for me to conceive of a generally applicable solution, so I'll just hack something together that works for me and share how if anyone wants to know. If that means any extra hooks or filters I'll open a new ticket. Thanks again.

[boonebgorges]

Thanks for the thoughts, terraling. If you, as someone running a multilingual site, come up with some concrete ideas for how BP might help ease the process, please feel free to raise them. Until then, I'm going to close this ticket.

[MindBorn]

I know it's 'kinda' old topic but I'd really love to hear how you finally solved it @terraling