[buddypress-trac] [BuddyPress Trac] #5669: Help plugins to generate activities for their post type(s)

[buddypress-trac]

#5669: Help plugins to generate activities for their post type(s)
-----------------------------------+------------------
 Reporter:  imath                  |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  2.2
Component:  Activity               |     Version:  2.0
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |
-----------------------------------+------------------

Comment (by imath):

 Thanks for you feedback boonebgorges. The i18n is giving me headaches !!
 I'll explain why after.

 First "new hook vs lazy-loading". Although I agree that the your lazy
 loading suggestion is very interesting, if you and the team don't mind, i
 think i'd rather use the hook as, in the end, i find it less risky.
 I can see how to use a function like
 {{{bp_activity_get_trackable_post_type( "post_type_to_check" )}}} when
 doing the transition post status stuff, as we actually need to get the
 tracking info.
 But i'm less sure about the other usage of this function that is to
 populate another global {{{buddypress()->activity->actions}}} so that in
 dropdowns it's possible to filter the activity stream by post types. I
 mean,
 1. for instance in {{{bp_activity_show_filters()}}}, it seems strange to
 me to call a function which would return nothing used directly.
 2. imho it would introduce some risks themes wouldn't get all the actions
 if they don't use the specific function before trying to get the activity
 types using the global {{{buddypress()->activity->actions}}} or the
 function {{{bp_activity_get_types()}}}

 So have a preference for the hook and if it's ok with everybody, i'll add
 a hook at the end of the function
 {{{bp_activity_tracking_register_post_types()}}}

 I'll correct the two points you mentioned about the unit tests.

 ==== Translation is giving me headaches!! ====
 But before all this, i think we need to find the best way to deal with
 translations. I'll first explain what i do in the patch. Unlike the
 'new_blog_post' action string, i chose not to fetch the title of the post
 to avoid a blogmeta. So the string looks like this :
 {{{
 __( [user_link] posted a new [post type link], on the site [blog_link] )
 }}}

 So as you can see there are 3 links. First and last are the same than in
 the 'new_blog_post' action but {{{[post type link]}}} is like this :
 {{{<a href="linktothepost">$post_type->labels->singular_name</a>}}}

 So having a {{{$post_type['labels']['bp_activity_new_post'] = __( '%s
 posted a new foo' )}}} is not very helpful in this case because foo is not
 a link. It could be {{{$post_type['labels']['bp_activity_new_post'] = __(
 '%s posted a new %s' )}}}, but it might confuse the plugin author :(

 I think we'll never find the perfect solution. What we're trying to do in
 the first place is to find a "generic" action. So it is necessarily
 problematic.

 Let's take an english example.

 imath posted a page > good
 imath posted a post > good
 imath posted a idea > not good

 So the word "new" is an interesting way to solve this issue in english.

 Let's look at french with the word new :
 imath a posté un nouvel article > good
 imath a posté un nouvel page > not good, it should be: imath a posté
 un'''e''' nouvel'''le''' page
 imath a posté un nouvel livre > not good it should be : imath a posté un
 nouve'''au''' livre

 A way to solve this in french would be to get rid of the new word and use
 something like un(e), e.g.:
 imath a posté un(e) livre

 So IMHO, i don't think sprintf is problematic as on the contrary it avoids
 wrong order comparing to concatenated strings.
 see
 http://codex.wordpress.org/I18n_for_WordPress_Developers#Best_Practices

 Finally, using the post type labels argument might not be the best way in
 my opinion.
 1. I think lots of people will use {{{add_post_type_support( 'book',
 'buddypress-activity' )}}} without being the plugin author, because it's
 easy.
 2. As a plugin author i think i would use the filter i've used in the
 Blogs loader class to define my own formatting function because anyway i'd
 need to set the component_id parameter to my component (by default it's
 the activity component)

 Argh. I'm disappointed and i lack ideas to solve this issue :(

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