Project:String Overrides
Version:6.x-1.7
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed (duplicate)

Issue Summary

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.

<?php
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

#1

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

#2

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.

#3

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:

<?php
$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.

#4

Status:needs review» closed (duplicate)

#1057894: Context Module Integration