[buddypress-trac] [BuddyPress Trac] #5401: Multilingual: send notifications in language of recipient, not sender

[buddypress-trac]

#5401: Multilingual: send notifications in language of recipient, not sender
-------------------------------+------------------------------
 Reporter:  terraling          |       Owner:
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Core               |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |
-------------------------------+------------------------------
Changes (by boonebgorges):

 * keywords:   => reporter-feedback


Comment:

 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.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5401#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac