I have a lot of panels to which I have added bits of text/HTML using the "New custom content" option of the Panels module.

By default, such text does not show up on the Translate Interface screen. How should I go about translating them?

Two approaches I have found are:

  • Changing the custom content text format to PHP code and printing the string(s) of text using t(). This then allows me to translate the strings on the Translate Interface screen, but I worry that injecting PHP code like this is a bad precedent.
  • Since I only have two languages, I can add a second piece of custom content that is localized in the other language. Then, I can add a visibility rule to each piece of custom content in Panels and set each piece to show only when the user's language matches the content language. This works but it is time consuming and ugly on the backend. It would be even worse if I decide to add more languages to my site in the future, which I may do.

Is there a more efficient, maintainable way to translate such custom content?

3 Answers 3


First of all, I would like to explain why this doesn't "just work", so that you have been given fair warning before I give you new problems. :) Consider a custom content pane content like:

Welcome %user:name, you have %field_num_messages new messages waiting.

The text here would be substituted before passed to t(), meaning that for each variation of user and number of messages, you would get an entirely new string to translate. For such panes, go with having two separate panes.

A long term solution is slowly being worked on here: Translatable panel titles: Implement i18n_strings but focuses on the pane titles initially.

Generally speaking, the solution is to avoid custom content panes, but I also realize that using them can be very convenient at times.

Finally, here's a piece of code I've used to "force" pane titles to become translatable. I will attempt to later modify it better to your situation, but I figured having a useful answer quickly was better than not. :) You should be able to use $pane to figure out if this is a custom pane, and then pass the text through t().

 * Implements hook_panels_pane_content_alter().
function HOOK_panels_pane_content_alter($content, $pane, $args, $context) {
  if ($content->title) {
    $content->title = t($content->title);
  return $content;
  • Ok, thanks! In this case, I don't have any custom content that uses the contexts, so at least I won't have the first problem you mentioned. Apr 20, 2012 at 7:00
  • This is no longer necessary, see drupal.stackexchange.com/a/108970/10086
    – Pere
    Apr 3, 2014 at 13:18
  • @Pere That is using the php module, which is a disaster waiting to happen.
    – Letharion
    Apr 4, 2014 at 10:35
  • @Letharion no, Panels translation module now is part of Panels, and does not use the PHP module
    – Pere
    Apr 4, 2014 at 13:41
  • @Pere You're right, apologies. For some reason on my phone the link showed me the answer above yours, so I misunderstood.
    – Letharion
    Apr 4, 2014 at 14:07

I use always a basic page, (existent node vs custom content). You will have this way trough Entity translation the opportunity to deal with languages and fallback. To avoid SEO duplicated content issues, install Rabbit hole module and use the redirect to your panel page for those nodes.


If your goal is to export some custom "blocks" (for lack of a better term) to code and translate them, you might consider using the boxes module with i18n_boxes, which will allow you to translate boxes in the UI (using l10n_client for example) and export the default language version to code. You can then use the boxes in your panels.

  • That's a good idea, but unfortunately there's a bug in Boxes right now that prevents it from saving settings unless you use the Context module as well. Boxes + Context is way too much overhead for this. drupal.org/node/1444544 Apr 24, 2012 at 23:57
  • Aren't you using Panels for display? The visibility settings of a box or block (from core) is not used with Panels, which is and of itself its own display engine, thus I dont think you need context in this case. Apr 26, 2012 at 11:36
  • Ah, that's right. However, if I were to go this route I would end up creating a large number of boxes which would become difficult to manage, especially for translators, since they would have to handle two interfaces (Panels + Boxes). I appreciate the idea though. Apr 28, 2012 at 6:57
  • FYI: i18n_boxes exposes the boxes content and title as i18n_strings compatible translatable strings. You can then use l10n_client module's onscreen translation toolbar-- the sublimely blue bar at the bottom of all pages --making translations super easy for translators. I don't know how far the rest of panels custom content panes integrates with i18n_strings, but I assume it is broken, as stated in the OP. May 12, 2012 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.