I appreciate this one is only a warning, and that there may be security reasons for insisting on the rule
This rule is at odds with object-oriented encapsulation:
WARNING | Only string literals should be passed to t() where possible
Example: in my educational OOE = Object Oriented Examples tutorial module (sandbox https://drupal.org/sandbox/webel/2120905) I have an interface IBlock and a class DefaultBlock that encapsulates a Drupal block. It has a private variable for the block $info, and this is used (with a lot of other stuff) to help build a Drupal block array that is then passes off to Drupal core:
class DefaultBlock implements IBlock {
/**
* From hook_block_info():
* 'The human-readable administrative name of the block.'
*
* 'This is used to identify the block on administration screens,
* and is not displayed to non-administrative users.'
*
* @var string
*/
private $info;
public function __construct($delta, $info) {
..
$this->info = $info;
}
/**
* Builds and returns a Drupal array compatible with hook_block_info().
*
* @return array
* A Drupal array compatible with hook_block_info().
*/
public function get() {
$out = array();
$out['delta'] = $this->delta;
$out['info'] = t($this->info);
// Coder: WARNING | Only string literals should be passed to t() ..
if (!empty($this->cache)) {
$out['cache'] = $this->cache;
}
if (!empty($this->properties)) {
$out['properties'] = $this->properties;
}
if (!empty($this->weight)) {
$out['weight'] = $this->weight;
}
if (!empty($this->status)) {
$out['status'] = $this->status;
}
if (!empty($this->region)) {
$out['region'] = $this->region->getName();
}
if (!empty($this->visibility)) {
$out['visibility'] = $this->visibility;
}
$pages = $this->getPages();
if (!empty($pages)) {
$out['pages'] = $pages;
}
return $out;
}
Coder triggers on this line:
$out['info'] = t($this->info);
Use of string literals is in such cases at odds with object-oriented encapsulation.
That said, I don't currently have any ideas how best to handle the above safely.