[buddypress-trac] [BuddyPress] #3856: Saving activity update action as an array in db

[buddypress-trac]

#3856: Saving activity update action as an array in db
-------------------------+------------------
 Reporter:  modemlooper  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  2.0
Component:  Activity     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------

Comment (by boonebgorges):

 terraling - Thanks very much for your feedback. Your use case
 (multilingual sites) is exactly the motivation for this change.

 The hack that you've put together - filtering
 `bp_get_activity_action_pre_meta` - is exactly what I would do in your
 position.

 A more general solution will have to be more general. In your
 `bp_get_activity_action_pre_meta` callback, you have the luxury of knowing
 which languages you need to translate into. So you can assemble a finite
 list of translations, and do the translations on the fly. BP itself
 doesn't have this luxury - you could be running in any one of dozens of
 languages. So what we'll have to do is to extend our activity API with
 dynamic callback functions. Something like:

 {{{
 bp_activity_add( array(
     // ...
     'action_callback' =>
 'bp_friends_new_friends_activity_action_callback',
     'action_callback_params' => array( $initiator_user_id,
 $friend_user_id, ),
     'type' => 'friendship_accepted',
     // ...
 ) );
 }}}

 {{{
 function bp_friends_new_friends_activity_action_callback(
 $initiator_user_id, $friend_user_id ) {
     $initiator_link = bp_core_get_userlink( $initiator_user_id );
     $friend_link = bp_core_get_userlink( $friend_user_id );
     return sprintf( __( '%1$s and %2$s are now friends', 'buddypress' ),
 $initiator_link, $friend_link );
 }
 }}}

 Then, when fetching the action in the template loop, we'll get the string
 from the callback function. This'll allow translation into arbitrary
 languages on the fly. (It's not too different in concept from what you and
 modemlooper have suggested with storing the gettext chunks in the DB.
 However, the callback technique accounts for the fact that different
 chunks will have different numbers of arguments to swap out, and the fact
 that translations may change over time.)

 This is off the top of my head, so the proposal needs lots of fleshing
 out. (There are issues with backward compatibility - dealing with plugins
 that don't provide the necessary callbacks - as well as the question of
 how much stuff should be stored in the DB and how much should be pulled up
 dynamically, and whether the dynamic fetching should be done inline or at
 the beginning of the activity loop. Etc etc etc.) But I would like to make
 it a priority for 2.0.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3856#comment:10>
BuddyPress <http://buddypress.org/>
BuddyPress