Allow translation of markup content

Exactly what I did... should be added to module. I don't want to give PHP access to content authors just so they can translate markup content fields. This also doesn't translate the PHP code which is good since PHP code can pass it's own stuff through t(). BTW, this is similar to #714748: i18n support which appears to be stuck in a rut... although it doesn't put translation code in the right place. That said the hangup on HTML seems ridiculous. If I want translatable content I'll be careful with what HTML I include.

I've created a patch to use the workaround in the description for D7

This probably doesn't take into account complex html, but the patch seems to work. I'd rather use a generic field translation however. Using entity_translation for instance.

I would also very much prefer the field translation behavior because otherwise we always have to go to ui translation and if the source markup changes, there is a new translation required.

I'd also like to add that t() should only accept a natural string, no variables. So this patch should always fail testing.

I eventually had to target this particular field in a hook_form_ENTITYFORM-TYPE_entityform_edit_form_alter and wrap the markup in a t() function.

I tested it with some strings containing html tags (p, span class="my_class") and it worked well.

Hm.. I think use hook_i18n_field_info is better than #2 patch.
With i18n integration, field can translate via i18n field ui.

As per the t() manual page

It is especially important never to call
t($user_text);
, where $user_text is some text that a user entered - doing that can lead to cross-site scripting and other security problems.

it's a big no-no to pass user supplied text through t(). So #2 is a no go for me (and should be for others).

This patch adds i18n_string/i18n_field integration to markup fields, also taking into account whether the set markup text format is allowed to be translated.

Patch #10 works for me! Thanks :)

#10 does not work with filters for untranslated markup.

This patch fix #10 patch for untranslated markup fields.

Fix mis typing on #15.

Couple of issues with #16

+++ b/markup.module
@@ -118,9 +118,22 @@ function markup_field_widget_form(&$form, &$form_state, $field, $instance, $lang
+  if (function_exists('i18n_string_translate')) {

I agree that using i18n_string_text() is better then what I used, but change to check for the new function you use.

+++ b/markup.module
@@ -144,3 +150,16 @@ function markup_form_alter(&$form, &$form_state, $form_id) {
+ * Implements hook_i18n_string_list_TEXTGROUP_alter().
+ */
+function markup_i18n_string_list_field_alter(&$strings, $type = NULL, $object = NULL) {

Whole hook from patch in #10 is missing, so now the string can't be translated via the field translation UI.

Manually tested with token_filter as format and #16 fixes the issues with it.

Had the changes here, so here is patch with the changes from #17 applied.

Re-rolled the patch to latest release.

I have removed the langcode from the options array, as it always comes as LANGUAGE_NONE.
Without the langcode mentioned, it will take the current one from i18n function.

@rbmboogie The patch in #20 appears to be an interdiff? It's not a complete patch.

Updated the issue summary to reflect the current state of the issue.

@lendude thanks for the fast reply.
Re-uploaded the combined patch from #19 and #20.

Tested it manually, and looks good to me.

Only thing I can think of would be adding some documentation, but since the module doesn't actually contain any documentation at the moment, that seems like a totally separate issue.

Patch #22 works good for me.
Note: This will only work for newly created fields.

+1 for #22

+1 for #22

Patch #22 works good for me too, also for existing fields.

I had to add the i18n_string translation to the hook_field_prepare_view as well to get it to appear translated on the view page (not just on the edit page).

+++ b/markup.module
@@ -52,10 +52,23 @@ function markup_field_formatter_prepare_view($entity_type, $entities, $field, $i
+    if ($instance['display']['default']['type'] == 'markup_view') {
+      // Translate the markup setting when possible.
+      if (function_exists('i18n_string_text')) {
+        $i18n_string_name = "field:{$instance['field_name']}:#field:markup";
+        $options = array(
+          'format' => $field['settings']['markup']['format'],
+          'sanitize default' => TRUE,       // Apply text filter for source.
+        );
+        $markup = i18n_string_text($i18n_string_name, $field['settings']['markup']['value'], $options);
+      }
+      else {
+        $markup = check_markup($field['settings']['markup']['value'], $field['settings']['markup']['format']);
+      }

Lots of code duplication in this. Shouldn't we just put all this in an internal function that you pass the instance?

It'd be a good idea. I'll update the patch.

Updated. Also updated the help text on the settings form.

From 1fe2ed21fae41b24607eb8a712df06b198f863dd Mon Sep 17 00:00:00 2001
From: t0xicCode <t0xicCode@888364.no-reply.drupal.org>
Date: Fri, 4 Dec 2015 13:43:48 -0500
Subject: [PATCH] Issue #1698102 by rbmboogie, Lendude, barami, t0xicCode,
 rvilar: Allow translation of markup content
 
---
 markup.module | 51 ++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 46 insertions(+), 5 deletions(-)
 

extra bit at the top of the patch. Applies cleanly though.

Manually tested the patch and looks good.

extra bit at the top of the patch. Applies cleanly though.

Oh, right. I tend to generate my patches using git format-patch, which formats the patch (which is already basically a commit) into an email message. git am can use the metadata in there to apply the patch more effectively.

+1 for patch from #34

#34 RTBC++

Q.
How to use patch #34?
I applied this patch, re-loaded the page in which my markup fields appear, and expected to see them available for translation via translate interface ( admin/config/regional/translate/translate ).
They are not.
How do I enter the translations?

A.
Use the field translation interface, e.g. admin/structure/types/manage/node_type/fields/field_name/translate

#22 works well for me. Thank you.

More than a year later... still running #34, still working good.
Can we get this patched please?

Using #34 and working like a charm. In case anyone else starts pulling their hair out after applying the patch -- remember to clear all your caches.

#22 works well ! Thank you.

i applied the patch from #34 and i am having the same question as was asked in #38. i am in the page admin/structure/types/manage/node_type/fields/field_name/translate for this field and i only see the values for the Title, not the Markup itself. i have cleared caches and it made no difference. any ideas, anyone?

Thank you all very much - I just committed this to the latest 7.x dev version!