I want to include a message that indicates where a block is located. Since I am terrible at other languages, I'm not sure what the best way is to handle the message. Here's the code the way I have it right now, but I think there, surely, must be a better way.

  if ($region) {
    switch ($region) {
      case 'left':
        $msg = t('It should appear in the list on the left side of the screen momentarily.');
        break;

      case 'right':
        $msg = t('It should appear in the list on the right side of the screen momentarily.');
        break;

      case 'header':
        $msg = t('It should appear in the list at the top of the screen momentarily.');
        break;

      case 'footer':
        $msg = t('It should appear in the list at the bottom of the screen momentarily.');
        break;

      default:
        $msg = t('It should appear in the list momentarily.');
        break;
    }
  }
  else { $msg = NULL; }

  drupal_set_message(t('Your question has been submitted.'.' '. $msg));

Comments

shakethetv’s picture

try it with foreach loop

nancydru’s picture

Huh? This is not really a code issue - it's a translation issue.

Perhaps I need to elaborate. The part in the default case ("It should appear in the list momentarily.") is common to all the strings. The others insert a few extra words (e.g. "on the left side of the screen", "at the top of the screen"). What I don't know is if inserting these phrases might, in some language, so totally change the context that it would not be correctly translatable.

  case 'left':
    $insert = 'on the left side of the screen';
...
  $msg = t('It should appear in the list !where momentarily.', array('!where' => $insert));
... or ...
  $msg = t("It should appear in the list $insert momentarily.")

I'm guessing that both options here would confuse POTX or the translator.

gábor hojtsy’s picture

Using $insert is impossible, this string will not be picked up by potx, as it is not a literal string.

In the other case, using @where instead of !where is desired, it is generally not a good idea to use the ! placeholder format, just to make sure everything goes right, once you make this a user input or something...

Also in this case, it really depends on the language which people translate to. Of course having standalone messages provides the best flexibility, especially if you have a small number of predefined options to work with for @where. But in this case, using a placeholder seems to be reasonable as I think the regions have so similar names as they will probably have similar translations in nature, which will fit with a placeholder. But then again, you have two different string format here, the text without any region and the text with a region. Separate them. So never do:

EXAMPLE OF BAD USE!
switch(...)
   ...
   $where = t('at the @where', array('@where' => 'top of the screen'))
   ...
   $where = '';
}

t('It should appear in the list !where momentarily.', array('!where' => where);
EXAMPLE OF BAD USE!

Do this instead, if you'd like to centralize the t() call:

if ($region) {
    switch ($region) {
      case 'left':
        $region_name = t('left side');
        break;
      case 'right':
        $region_name = t('right side');
        break;
      case 'header':
        $region_name = t('top');
        break;
      case 'footer':
        $region_name = t('bottom');
        break;
      default:
        $region_name = '';
        break;
    }
    if ($region_name) {
      $msg = t('It should appear in the list at the @region of the screen momentarily.', array('@region' => $region_name));
    }
    else {
      $msg = t('It should appear in the list momentarily.');
    }
  }
  else { $msg = NULL; }

  drupal_set_message(t('Your question has been submitted.'). $msg));

Also note that we don't do string concatenation in drupal_set_message()'s t() either. None of the t() calls allow any dynamic string composition, be it either substring replacement with $region_name and such or string concatenation.

Your thoughtful support questions motivated me in part to do the Drupal 6 translation cheat sheet and coder module integration. The cheat sheet which should give good general advice to Drupal 5 developers too. I'd love your feedback on it. What is not clear in the light of the support requests we are going through, what is missing, what is explained in too much of a detail? (BTW I think your support requests make a good FAQ, and I am glad that there are contrib maintainers actually asking these questions :)

nancydru’s picture

Thanks, Gábor. I used a ! placeholder because this data is hard-coded and will never be user-input, so I didn't see any point to the extra overhead of a check_plain call.

I'm sure as more people try this module, they'll be telling more region names, so I can see this getting to be a significant list. That worried me that the code could get VERY large very quickly. This should help limit the size.

I will check out the cheat sheet shortly. Thank you for doing it. I'll also go back and link some of my handbook pages to it.

nancydru’s picture

Status: Active » Closed (fixed)