I had a project (now abandoned) where string overrides were to be managed on a per-group basis. The idea was to use the nid in place of the language code. Here is about as far as I got; its just proof of concept at this stage, but it works.

function og_stringoverride_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  
  // okay the concept works. next steps would be:
  // add a UI on a per-node level
  // figure out how to propagate parent overrides to children in a sub-group setup
  // create a new table to store this in. it could get out of hand if the 
  //    variables is used. load in those values here.
  // what impact does this have on multi-lingual sites?
  
  global $language;
  global $conf;
  
  if ($op == 'load' && $language->language == 'en') {
    $language->language = $node->nid;
    $conf['locale_custom_strings_1'] = array('My Unread' => 'Unread that is mine');
  }
}

I wanted to do this for a site where there were dozens of system strings that were generally the same from group to group, but would sometimes need to be tweaked on just one. I thought this would be a nice way to handle it instead of adding dozens of CCK fields or the like.

Hope someone finds this concept useful.

Comments

robloach’s picture

robloach
he/him
commented

I like the idea, a lot. Not sure how the UI for this would be though. Any thoughts?

gcassie’s picture

gcassie commented

Perhaps another tab on the group node which pulled in the string overrides form, but saved the values to the appropriate variable? I suppose if the variable table was in danger of growing too large you could define a new table and merge in the og-specific overrides as needed.

If there were a contextual menu-like module that attached a "translate" menu to all t() strings, that would make it simple for the group admin to discover which strings were overridable - could be linked to the override form for the group.

btopro’s picture

btopro commented

Bump;

I was just having a discussion and this idea came up (OG specific overrides). You can get the current group context and see if it's a group node as follows:

$group_node = node_load(arg(1));
    if(og_is_group_type($group_node->type)){
      og_set_theme($group_node);
      og_set_group_context($group_node);
      og_set_language($group_node);
}

This will take the group into account and set the context. I use this snippet for some other modules when adding tabs to the group-nodes page. Then you could get the context while on another page to have the current node's group and then set the language accordingly (instead of using the og_set_language.

Allowing users on a per-group basis to alter menu language could be an incredibly powerful, especially from a usability perspective.

robloach’s picture

robloach
he/him
commented
Status: Needs review » Closed (duplicate)

#1057894: Context Module Integration