I've changed the buddylist translation array to use network and member instead of buddylist/buddy. This is great but now I have some messages that don't quite make sense and no way to fix them other then to alter the buddylist.module code.

For instance


drupal_set_message(t('Congratulations! !linktouser is now your @buddy.', array('!linktouser' => theme('username', $requester_account)) + buddylist_translation()));
}
else {
drupal_set_message(t("!user's request to be your @buddy has been denied.", array('!user' => theme('username', $requester_account)) + buddylist_translation()));

produces "Congratulations! theDude is now your member".

I'd prefer "Congratulations! theDude is now a member of your network"

Looks like another addition to the buddylist settings.

Comments

dldege’s picture

dldege commented

In general pretty much all of the parts of buddy list that end up in UI elements should be thememable including all the status messages, etc.

For example,

in 

  global $user;
  
  $account = user_load(array('uid' => $id));
  
  $viewing_own_account = ($user->uid == $id);
  
  $result = db_query('SELECT bpr.requestee_uid as uid, u.name FROM {buddylist_pending_requests} bpr INNER JOIN {users} u ON bpr.requestee_uid = u.uid WHERE requester_uid = %d', $account->uid);
  
  if (!db_num_rows($result)) {
    $output = t('!Person !do_or_does not have any pending @buddy requests that !person !have_or_has made.', 
                array(
                  '!Person' => ($viewing_own_account ? t('You') : $account->name), 
                  '!do_or_does' => ($viewing_own_account ? t('do') : t('does')), 
                  '!have_or_has' => ($viewing_own_account ? t('have') : t('has')), 
                  '!person' => ($viewing_own_account ? t('you') : $account->name) ) + buddylist_translation());
  }
  else {
    $output = t('!person !have_or_has requested to be added to the @buddylist of the following users.', array('!person' => ($viewing_own_account ? t('You') : $account->name), '!have_or_has' => ($viewing_own_account ? t('have') : t('has'))) + buddylist_translation());
  
    $html_rows = array();
    while ($row = db_fetch_object($result)) {
      $html_row = array();
      $html_row[] = theme('username', $row);
      $html_row[] = drupal_get_form('buddylist_request_cancel_form', $row->uid, $id);
      $html_rows[] = $html_row;
    }
    
    $output .= theme('table', NULL, $html_rows);
    
  }
  
  return $output;

}

it would be ideal if both cases of output were themeable instead of hard coding the no pending case and themeing to a table for the other case.

Also, throught the code it probably would make sense to use theme('username',$account) instead of $account->name. I ran into this because I theme usernames into full names like John Smith vs. using his account name of jsmith. Buddylist uses jsmith in all of its messages.

fago’s picture

fago
Primary language German
Location Vienna
commented

yep, theme('username', .. would be better.. Feel free to run a patch for this. Recent I've replaced a lot of hardcoded links with $user->name by the theme function.

I agree that the status messages should be customizable. However making them all configurable through the admin settings might blew this up more and most of the message customization might be needed by people that also customize the buddylist translations - so I think best would be to simply use variable_get() for all the messages, so people could override them like the buddylis-ttranslations in their configuration file (settings.php).

dldege’s picture

dldege commented

OK, I'll see about a patch for the username themeing.

Regarding the other I think a way to replace/change all strings sounds great but I would still suggest a more granular theme design for buddylist so that instead of calling theme('table') maybe we do something like theme("buddylist_buddylist_pending", theArrayOfPendingRequests)

Then the theme could show that in a table or what ever else they choose. This would also remove my earlier request to provide ways to theme the tables since now you could totally build the table in your own theme or do a non-table version.

Thoughts?

fago’s picture

fago
Primary language German
Location Vienna
commented

sounds like a good idea, however my personal favorite is to replace all this listings with views.. however, this would require a views and usernode module dependency.

dldege’s picture

dldege commented

I think the module should support a base themeing model that does not require any other modules like views but that views support is certainly and good addition. It seems the buddylist made some attempts at this with a couple of theme hooks but just needs to be more granular. I don't have time to work on this right now as I have a project deadline soon and must just work with what is there - but if anyone else has time that would be great.

fago’s picture

fago
Primary language German
Location Vienna
commented

yep, integrating views would be a bigger task.
I've just introduced a first theme function for the new pending requests tab.

however, introducing a extra theme function for each table is imho too much. it should already be themeable by overriding theme_table appropriate. imo the ideal flexibility would we be achieved by using views.

dldege’s picture

dldege commented

Is there a way to override theme('table') just for buddylist or as I found you would override all tables in the site?

fago’s picture

fago
Primary language German
Location Vienna
commented

you would override all tables, however you could easily adapt this with a check like this

if (arg(0) != 'buddylist')
return theme_table($args...);

dldege’s picture

dldege commented

Ah, yeah, I should have realized that - thanks.