To make the markup translatable, I altered the code in form_markup.module near line 32

from

function form_markup_add_markup(&$form) {
  $fields = content_fields(NULL, $form['type']['#value']);
  if (is_array($fields)) {
    foreach ($fields as $field_name => $field) {
      if (is_array($form[$field_name])) {
        $form[$field_name]['#prefix'] =  $field['widget']['prefix'] . $form[$field_name]['#prefix'];
        $form[$field_name]['#suffix'] .= $field['widget']['suffix'];	       
      }
    } 
  }     
}

to

function form_markup_add_markup(&$form) {
  $fields = content_fields(NULL, $form['type']['#value']);
  if (is_array($fields)) {
    foreach ($fields as $field_name => $field) {
      if (is_array($form[$field_name])) {
        $form[$field_name]['#prefix'] =  $field['widget']['prefix'] . $form[$field_name]['#prefix'];
        $form[$field_name]['#suffix'] .= $field['widget']['suffix'];
        
        if ($form[$field_name]['#type'] == 'markup') {
          $form[$field_name]['#value'] = t($form[$field_name]['#value']);
        }       
      }
    } 
  }     
}

Comments

smoothify’s picture

Status: Active » Postponed (maintainer needs more info)

This would be a nice to have - but I'm not sure if translating the entire markup field is the best way to approach this as there is likely to be lots of html markup (and soon php code) in there.

There should be a better way of making the markup field itself translatable through the i18n interface - but that needs some further research.

zilverdistel’s picture

You're absolutely right, this is not the way to go.

smoothify’s picture

I have created an issue in the i18n queue asking for advice on how to make a field setting translatable.

#1004370: How to make a CCK widget setting translateable?

In the meantime, the new php code functionality and Markup View module may both offer ways of delivering customized content to different languages. Both are available in the latest dev release.

zilverdistel’s picture

Great, I'm subscribing on the other issue too. Let me know if I can help.

liquidcms’s picture

bumping this to D7 and wondering why still an issue; i would have thought with the Field API this would now be automatic; but isn't. perhaps something needed in the markup "property" definition to define it as translatable?

bcostlow’s picture

A couple of things:

  • Markup can (and often does) contain HTML tags, which is typically a no-go for translation using t().
  • Since PHP can be used with Markup, making these values translatable creates a security risk where raw PHP would be exposed in the translation interface and could be altered.

While certainly not ideal, you can get this functionality using PHP and passing your text through t() and printing it.

However, not translating text where HTML tags are possible is common practice in Drupal as far as I'm aware.

I'm not that familiar with i18n support though, so if you (or anyone) has any suggestions I'd be happy to hear them!

liquidcms’s picture

not translating text where HTML tags are possible is common practice in Drupal as far as I'm aware

hmm.. sorry, don't get that... everything must be translatable - this module isn't usuable on a lot of sites if there is no way to translate the markup.

and not sure what the t() would be for here; that isn't the way to do this.. the trick is to have it show in the page you get from the translate tab which shows when editing a field. this is called from the i18n_field_page_translate() function. i think it loads up the field instances and the field settings to allow translation; and for some reason the markup field doesn't show as one of these.

i will figure it out. :)

interjinn’s picture

Similar to #1698102: Allow translation of markup content which places the translation in a better location in the source code to prevent translation of PHP output (which is likely to be dynamic anyways).

lendude’s picture

Issue summary: View changes