If you add a block and try to create a translation for the content, the body field will simply show html because no javascripts for rich text editors are loaded.
The editor works fine for default block language or nodes etc.
But for example on de/admin/structure/block/manage/block/2/translate/en?destination=admin/structure/block/manage/block/2/translate no rich text editor will load.
I use Wysiwyg 7.x-2.1 and Tinymce 3.4.3.2.
The problem seems to exist for ckEditor too: http://drupal.org/node/1227472

Files: 
CommentFileSizeAuthor
#80 1252144-80-support-wysiwyg.patch9.16 KBfietserwin
PASSED: [[SimpleTest]]: [MySQL] 2,095 pass(es).
[ View ]
#75 1252144-74-support-wysiwyg.patch7.88 KBfietserwin
FAILED: [[SimpleTest]]: [MySQL] 2,091 pass(es), 5 fail(s), and 0 exception(s).
[ View ]
#57 i18n_string-Support-text-format-elements-fix-1252144.patch3.11 KBalmul0
FAILED: [[SimpleTest]]: [MySQL] 2,091 pass(es), 5 fail(s), and 0 exception(s).
[ View ]
#56 i18n_string-Support-text-format-elements-1252144.patch3.09 KBalmul0
FAILED: [[SimpleTest]]: [MySQL] 2,061 pass(es), 32 fail(s), and 7 exception(s).
[ View ]
#40 i18n_wysiwyg_block_fix.zip853 bytesblackandcode
#32 i18n-added-support-wysiwyig-editors-for-string-translations-1252144-32.patch3.86 KBzilverdistel
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in i18n-added-support-wysiwyig-editors-for-string-translations-1252144-32.patch.
[ View ]
#20 i18n_text_format_1252144_18.patch2.99 KBdimitriseng
FAILED: [[SimpleTest]]: [MySQL] 1,889 pass(es), 5 fail(s), and 0 exception(s).
[ View ]
#18 i18n_text_format_1252144_18.patch2.99 KBdimitriseng
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i18n_text_format_1252144_18.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#12 i18n_text_format_1252144_12.patch3.84 KBnikosnikos
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i18n_text_format_1252144_12.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Title:Wysiwyg Javascripts don't get loaded for block translationsSupport Wysiwyg editors for string translations (Wysiwyg Javascripts don't get loaded for block translations)
Category:bug» feature
Priority:Major» Normal

I think this is a general issue with all the string translation system, not only for blocks.
And yes, it would be a nice feature to add.

(Maybe adding some class to all translation textareas with string formats?)

Hi,
I found also this post D7: ckEditor does not show up on block translation. Didn't find anything on the subject in Wysiwyg module's issues, and for the moment didn't find anything that solves the problem...

Will continue searching a solution, but if somebody has an option to propose, I'm listening :-)

That's really bad. So you can't easily use Drupal's block system with translations when the customer (not knowing HTML, and not to forget: no RTE-functions) has to edit the translations.
But it seems that Drupal is not very often used with multiple languages?!

edit: I've thought about that and using node_block module it is possible to let users edit translations by using an RTE. node_block is a great module though.

I'm also looking for any solution…

Here a workaround but i don't think is the best way :
Create a new module "mymodule" and copy/paste :

<?php
/*
* Implements hook_form_alter()
*/
function mymodule_form_alter(&$form, &$form_state, $form_id){
    if(
$form_id == 'i18n_string_translate_page_form'){
        foreach(
$form['strings'] as $name => $field){
            if(
preg_match('/blocks:block:[0-9]+:body/i',$name)){
               
// Change textarea to text_format
               
$form['strings'][$name]['#type'] = 'text_format';
               
$form['strings'][$name]['#description'] = '<br/>';
            }
        }
    }
}
?>

Well, the editor appears but for me saving isn't possible. I get following error:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''rte' WHERE ( (lid = '6989') AND (language = 'en') )' at line 1: UPDATE {locales_target} SET translation=:db_update_placeholder_0_value, :db_update_placeholder_0_format WHERE ( (lid = :db_condition_placeholder_0) AND (language = :db_condition_placeholder_1) ); Array ( [:db_condition_placeholder_0] => 6989 [:db_condition_placeholder_1] => en [:db_update_placeholder_0_value] =>

Testcontent with HTML

[:db_update_placeholder_0_format] => rte ) in i18n_string_textgroup_default->save_translation() (Zeile 649 von modules/i18n/i18n_string/i18n_string.inc).

Searching for content in linkit doesn't work either. I guess it's not solved that easily.

chymz workaround makes wysiwyg editor appear but like skks already mentioned you can't save. That is because wysiwyg editor returns in addition to field value its format and i18n can't handle it. Solution- add another submit function to form that removes format from values.

<?php
function mymodule_form_alter(&$form, &$form_state, $form_id){
  if(
$form_id == 'i18n_string_translate_page_form'){
    foreach(
$form['strings'] as $name => $field){
          if(
preg_match('/blocks:block:[0-9]+:body/i',$name)){
             
// Change textarea to text_format
             
$form['strings'][$name]['#type'] = 'text_format';
             
$form['strings'][$name]['#description'] = '<br/>';
          }
      }
     
$form['#submit'] = array_merge(array('mymodule_string_translate_page_form_submit'), $form['#submit']);
  }
}
function
mymodule_string_translate_page_form_submit($form, &$form_state) {
 
//Remove wysiwyg format because i18n cant handle it
 
foreach($form_state['values']['strings'] AS $name => $field) {
    if(
preg_match('/blocks:block:[0-9]+:body/i',$name)){
      unset(
$form_state['values']['strings'][$name]['format']);
    }
  }
}
?>

#7 works well thank you ! (and thank you chyzm for the first shot ^^)

Hello Guys

Thanks for coming up with this great fix. Since i am not a developer yet, and really need this on a client project, can someone share the solution here or email it to me at: exhimitiku@gmail.com

Thanks a lot

For those who do not know how to create a module, here is a little one based on this fix :
http://drupal.org/sandbox/DuaelFr/1347748

Just what I needed, thanks!

StatusFileSize
new3.84 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i18n_text_format_1252144_12.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I had the same problem with taxonomy terms translations. I also think (like Jose Reyero) that it it would be a really nice feature to add.

I wrote a patch. The patch integrate the solution in #7 into i18n module. It is necessary to clear the cache to make it work.

Thanks a lot nikosnikos! Your patch works very well! I hope this small modify can be committed very soon!

thank you! it worked for me too!

Status:Active» Reviewed & tested by the community

I forgot to change the status to "needs review" in #12... I set the status to RTBC if this have to be "needs review" you can change it.

Status:Reviewed & tested by the community» Needs work

The last submitted patch, i18n_text_format_1252144_12.patch, failed testing.

damned ! I suppose I should port my patch on the last dev to have a chance to pass the tests but I don't have time for the moment.

Version:7.x-1.0-rc3» 7.x-1.4
Status:Needs work» Needs review
StatusFileSize
new2.99 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch i18n_text_format_1252144_18.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I have tested the patch at #12 against the latest stable version of i18n, 7.x-1.4 and Drupal 7.12 and wysiwyg 7.x-2.1 with CKEditor, thanks for this. I can confirm that the patch is working ok and the WYSIWYG editor is now showing up ok for the translation. Also the translation is saved correctly.

The only issue I can see so far is at the following lines:

  if (!locale_string_is_safe($value)) {
    form_set_error($formkey, t('The submitted string contains disallowed HTML: %string', array('%string' => $value)));
    watchdog('locale', 'Attempted submission of a translation string with disallowed HTML: %string', array('%string' => $value), WATCHDOG_WARNING);
  }

I am using a custom text format which is similar to the Full HTML format and does not limit the tags that can be added.

I can add any tag to the original version of the block, but when I translate it, I am getting the error "Attempted submission of a translation string with disallowed HTML: ..." when I include tags such as <u> and other common tags such as for tables etc.

Also, this is not printing the exact tag that caused the issue or any other information that could help (have a look at #1020842: Error messages when importing translated strings fails are not helpful at all.

This seems to be coming from the "locale_string_is_safe" call and I have seen a few issues around this causing issues with translations, such as the issue above.

In order to get around this problem, I have applied the patch but I have commented out the code above from the i18n_string.pages.inc file and this now allows me to enter any tag as required. I understand that this might be dangerous so I guess that somehow we should be able to define the same restrictions as for the text format used for the original. It is interesting to note that I can add those disallowed tags if I translate the block body in the String Translation interface, but in that case I cannot use the WYSIWYG editor.

I have attached a patch based on #12 but against i18n 7.x-1.4 which is essentially the same but applies to the latest stable version.

Can you please test this patch and also provide any suggestions around the issue with the tags not being allowed? This would probably require some change in the i18n_string_validate_submission function in the i18n_string.pages.inc file. As mentioned above, my solution was to comment out those lines, but I don't think this is the correct solution. It would be great to get this to work properly as this is a quite useful feature. Thank you.

Status:Needs review» Needs work

The last submitted patch, i18n_text_format_1252144_18.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new2.99 KB
FAILED: [[SimpleTest]]: [MySQL] 1,889 pass(es), 5 fail(s), and 0 exception(s).
[ View ]

Status:Needs review» Needs work

The last submitted patch, i18n_text_format_1252144_18.patch, failed testing.

Scince v1.4 of internationalization the array $form['strings'] contains an extra dimension ['all'].

changing
foreach($form['strings'] as $name => $field){
into
foreach($form['strings']['all'] as $name => $field){
fixed it for us

@ #18
Here you have more information about that: http://drupal.org/node/1437146#comment-5745060

#22 - This works for me. Module versions i18n-1.4 and ckeditor-1.8. Thank you mpp.

@mpp and f4o - In which file did you make the change described in #22, I cannot find this line anywhere in the i18n module's files. Also, do you mean that by just making this change the WYSIWYG editor appears without having to apply this patch? Thanks.

Now that #1437146: Rework string translation access. (After 1.4 update, block translation disallowed HTML error) has been fixed it would be great to have this working too.

@dimitriseng, you need to create your own custom module and put hook function there. Here is my code in my i18nblocktran.module file

<?php
function i18nblocktran_form_alter(&$form, &$form_state, $form_id){
  if($form_id == 'i18n_string_translate_page_form'){
    foreach($form['strings']['all'] as $name => $field){
          if(preg_match('/blocks:block:[0-9]+:body/i',$name)){
              $form['strings']['all'][$name]['#type'] = 'text_format';
              $form['strings']['all'][$name]['#description'] = '<br/>';
          }
      }
      $form['#submit'] = array_merge(array('i18nblocktran_string_translate_page_form_submit'), $form['#submit']);
  }
}
function i18nblocktran_string_translate_page_form_submit($form, &$form_state) {
  foreach($form_state['values']['strings'] AS $name => $field) {
    if(preg_match('/blocks:block:[0-9]+:body/i',$name)){
      unset($form_state['values']['strings'][$name]['format']);
    }
  }
}

@f4o thanks for the clarification, I will give it a try. However, I think that it would be preferable to incorporate this into the i18n module, instead of having to create a custom module just for this (I am sure everybody already has loads of modules...). So, is it possible to provide this as a patch to i18n to be made available in the next release? I am happy to test if a patch is made available, thank you.

Sure, everybody has loads of modules. But for features depending on other contrib modules, see http://drupal.org/project/i18n_contrib

Anyway, if we find out why the editor is not kicking in, we can try to fix it. Maybe the module running after our form_alter because of module weights?

Version:7.x-1.4» 7.x-1.5

@Jose - Any ideas on a patch for this that will not require the installation of another custom module? This is still not working against 7.x-1.5. Many thanks.

I got this error when I applied the custom module fix from #26

Warning: html_entity_decode() expects parameter 1 to be string, array given in decode_entities() (line 429 of /includes/unicode.inc).
Notice: Array to string conversion in drupal_validate_utf8() (line 1600 of /includes/bootstrap.inc).
Warning: preg_match() expects parameter 2 to be string, array given in drupal_validate_utf8() (line 1606 of /includes/bootstrap.inc).

I managed to workaround this by moving the custom submit function to #validate instead, I guess i18n_string does some validation that doesn't like the 'format' variable.

Did anybody have any luck in getting this to work yet? Thank you.

Version:7.x-1.5» 7.x-1.x-dev
Component:Blocks» Strings
Status:Needs work» Needs review
StatusFileSize
new3.86 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in i18n-added-support-wysiwyig-editors-for-string-translations-1252144-32.patch.
[ View ]

Attached is a patch for the latest git (7.x-1.x). It's basically the same code as in #20. I only tested on taxonomy term translations, and it works.

I had to work with the dev version because of http://drupal.org/node/1437146#comment-6022282. That comment also states that you need the 7.2 branch of the variable module (hint: first upgrade the variable module, then the i18n module).

I changed the version, and also I think this issue belongs to the "Strings" component. Correct me if I'm wrong!

Greetings,

Diederik

Status:Needs review» Needs work
Issue tags:-block translation, -tinymce wysiwyg

Status:Needs work» Needs review

Status:Needs review» Needs work
Issue tags:+block translation, +tinymce wysiwyg

it works well, but now i got some js errors with the media module, it seems that it doesn't convert well media img.
If you switch Enable rich-text (or not), an error appears in debug and changes are not applied on save.

attributes.view_mode is undefined

// Remove elements from attribs using the blacklist
    for (var blackList in Drupal.settings.media.blacklist) {
      delete mediaAttributes[Drupal.settings.media.blacklist[blackList]];
    }
    tagContent = {
      "type": 'media',
      // @todo: This will be selected from the format form
      "view_mode": attributes['view_mode'].value,
      "fid" : attributes['fid'].value,
      "attributes": mediaAttributes
    };
    return '[[' + JSON.stringify(tagContent) + ']]';

Ok this had nothing to do with the hack, it was about the class media-image which was enabled on static html img code (no using the media syntax). Just delede this class to static image.

#32 works great for me on 7.x-1.7

I applied patch: #32. Everythink is ok on taxonomy term save but when I'm try to save something else I receive this error:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''full_html' WHERE ( (lid = '20566') AND (language = 'en') )' at line 1: UPDATE {locales_target} SET translation=:db_update_placeholder_0_value, :db_update_placeholder_0_format WHERE ( (lid = :db_condition_placeholder_0) AND (language = :db_condition_placeholder_1) ); Array ( [:db_condition_placeholder_0] => 20566 [:db_condition_placeholder_1] => en [:db_update_placeholder_0_value] =>

more

[:db_update_placeholder_0_format] => full_html ) in i18n_string_textgroup_default->save_translation() (line 681 of /var/www/vhosts/cdm.bild-studio.me/httpdocs/sites/all/modules/i18n/i18n_string/i18n_string.inc).

Someonehas mention this earlier: on comment #6

StatusFileSize
new853 bytes

Here is my patch for issue i mention in comment #39.

I made custom module and attach it. I modified code on comment #7. The key thing is i made it work for peple that use fieldgoups. You can see what I'm talking on this image:
https://dl.dropbox.com/u/58822631/drupal/bags/i18n_string_translate_edit...

#26 was what worked for me with CKEditor 7.x-1.9 and Internationalization 7.x-1.7

I personally prefer to create a custom module (which is very simple and quick) rather than applying a patch on i18n because then I believe I would need to re-apply the patch every-time I want to update i18n. Or worse maybe I'll update i18n and erase my patch. But maybe I don't apply patches the right way ?

Thanks anyway for the code !

Anyone know what the reason is for this not being worked into the official source already?

The suggested module from #7 and #26 works great! With little modifications:

  1. The block's title is turned into a textfield again (I do not know why this becomes a textarea on translation pages) and
  2. It also works for taxonomy terms.

Thanks a lot!

<?php
/**
* Implements hook_form_alter().
*/
function mymodule_form_alter(&$form, &$form_state, $form_id) {
  if (
$form_id == 'i18n_string_translate_page_form') {
   
// Loop all strings.
   
foreach ($form['strings']['all'] as $name => $field) {
     
// The field for [ block title / vocabulary name / vocabulary description / term name ] are textfields in ori language,
      // but textareas when translating: change these to textfields.
     
if (
       
preg_match('/blocks:block:[0-9]+:title/i' , $name) ||
       
preg_match('/taxonomy:(vocabulary|term):[0-9]+:name/i' , $name) ||
       
preg_match('/taxonomy:vocabulary:[0-9]+:description/i' , $name)
      ) {
       
$form['strings']['all'][$name]['#type'] = 'textfield';
      }
     
// Change textarea to text_format and overwrite description which is already auto included in text_format fields.
     
elseif (
       
preg_match('/blocks:block:[0-9]+:body/i' , $name) ||
       
preg_match('/taxonomy:term:[0-9]+:description/i' , $name)
      ) {
       
$form['strings']['all'][$name]['#type'] = 'text_format';
       
$form['strings']['all'][$name]['#description'] = '<br />';
      }
    }
   
// Add submit function.
   
$form['#submit'] = array_merge(array('_mymodule_form_submit') , $form['#submit']);
  }
}
function
_mymodule_form_submit($form, &$form_state) {
 
// Remove wysiwyg format because i18n cant handle it.
 
foreach ($form_state['values']['strings'] as $name => $field) {
    if (
     
preg_match('/blocks:block:[0-9]+:body/i' , $name) ||
     
preg_match('/taxonomy:term:[0-9]+:description/i' , $name)
    ){
      unset(
$form_state['values']['strings'][$name]['format']);
    }
  }
}
?>

Thanks lmeurs! Your solution worked great for me!

Status:Needs work» Needs review
Issue tags:-block translation, -tinymce wysiwyg

#12: i18n_text_format_1252144_12.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+block translation, +tinymce wysiwyg

The solution in #43 worked great for me as well. Thanks lmeurs!

+1 for #43.
Thanks lmeurs and all!

#43 definitely works..
Many thanks to lmeurs and all other guys!

I had the same problem, and solved using the lmeurs code at: #43.

Now the problem is that when I go back to edit the block translation the "body" doesn't remember the selected "Text format". The first one is selected, which in my case is Filtered Html even when I selected Full Html when I created the translation.

how can I solve this?

I use ckeditor.

I have a problem with this implementation. I enabled the "field translation" module, and when I try to translate a field name, an error occured and say there is no "all" index found in the form.

I think you can easily reproduce the problem by enabling "field translation" and navigate to /admin/structure/types/manage/[a-content-type]/fields/[a-field]/translate/[an-enabled-language].

there is no "all" index, there is "instance" and "field" index.

Hi titouille,

Apparently there are no strings defined for your form yet, try putting the first foreach block inside the next if statement:

<?php
if (isset($form['strings']['all'])) {
 
// First foreach block goes here.
}
?>

Thanks lmeurs. And sorry, I didn't have time yesterday to tests and complete my thread. There is strings defined, but not in the "all" index. On this form, there is strings in "instance" and "field" index. But it seems these translations doesn't require wysiwyg support, or maybe only for the description field ?

This is my "semi-" final solution :

<?php
   
foreach( $form['strings'] as $key => $category ) {
      foreach(
$category as $name => $field ) {
        if (
         
preg_match('/blocks:block:[0-9]+:title/i' , $name) ||
         
preg_match('/taxonomy:(vocabulary|term):[0-9]+:name/i' , $name) ||
         
preg_match('/taxonomy:vocabulary:[0-9]+:description/i' , $name)
        ) {
         
$form['strings'][$key][$name]['#type'] = 'textfield';
        }
       
// Change textarea to text_format and overwrite description which is already auto included in text_format fields.
       
elseif (
         
preg_match('/blocks:block:[0-9]+:body/i' , $name) ||
         
preg_match('/taxonomy:term:[0-9]+:description/i' , $name)
        ) {
         
$form['strings'][$key][$name]['#type'] = 'text_format';
         
$form['strings'][$key][$name]['#description'] = '<br />';
        }
      }
    }
?>

In this case, all indexes in $form['strings'] are managed and we can add new preg_match if needed for field translation management

Unfortunately, solution #43 doesn't work for me. I even upgraded to new version of internationalization suite, WYSIWYG module, but still no luck. Any ideas or any one else in my boat?

Thanks
Dan

StatusFileSize
new3.09 KB
FAILED: [[SimpleTest]]: [MySQL] 2,061 pass(es), 32 fail(s), and 7 exception(s).
[ View ]

I have been working on support translatable entity properties with formatted text for entityform, in conjunction with this patch http://drupal.org/node/1973024#comment-7389780.

I have modified the way that a translatable string is handled by i18n_string in order to suppor a formatted string of type:

<?php
$string
= array(
 
'value' => 'My string',
'format' => 'filtered_html');
?>

Even editing, note that the selected format in translation page is dismissed on the submit, because the source is the element thtat takes control over translations.

The patch is applied from the root of i18n.

StatusFileSize
new3.11 KB
FAILED: [[SimpleTest]]: [MySQL] 2,091 pass(es), 5 fail(s), and 0 exception(s).
[ View ]

The patch posted above is invalid, cause it breaks the default formatting option 'format'. Here it is an updated version of that patch.

Sorry for the mistake,
regards.

@#55: I met the same problem as you.

My solution was, in the _mymodule_form_submit() function, to replace the given instruction by the following:

$form_state['values']['strings']["my_field_key"] = $form_state['values']['strings']["my_field_key"]["value"];

@57 the patch doesn't works for me.

I don't see the wysiwyg editor, and also It doesn't let me to edit the html content.

Oskar

All, thanks for the great work on this.

Is there a "final" or most recent cumulative version of this fix? I sort of got lost in the thread and the different suggestions/patches. Is #43 ok?

Thanks

Status:Needs work» Needs review

Set to needs review to test last patch

Status:Needs review» Needs work

The last submitted patch, i18n_string-Support-text-format-elements-fix-1252144.patch, failed testing.

#59 You are right, the wysiwyg is not loaded even it adds format support for the textarea.

For the second, check that you have a field source to translate, otherwise, the translation field will be disabled.

almul0

I was reviewing the patch, and I guess the problem is that the 18n_block.test is not supporting formatted translations. But this is only a theory. I have no experience at TestCases and any help on it would be appreciated.

I have tested the block translation on a site and gives no error nor strange behavior.

almul0

Instead of try a patch for i18n, why not to build a module with #43

@people: Try this module https://drupal.org/project/nodeblock

@chefnelone, instead of use node as block, that it's a big mistake the best options is https://drupal.org/project/bean , with Bean you have a new kind of entity, you can translate it, export the entity to features, use fields with it, and you can have the permissions to avoid people see then like happens when you use node as blocks.

Oskar

My view is that if it is possible, then this should be provided as part of the i18n module, and if more advanced functionality is required then one of the other modules mentioned could be used. Not sure if anybody can do this based possibly on #43. Thank you.

@oskar_calvo why is it a big mistake to use nodeblock, have you really tried it?. With nodeblock you just works with nodes and block, as usual. Then you can add fields, translate and everything you do with standars nodes. I've been working with these modules for months now I have cero problems at all. I'm not going back in this.

@chefnelone use node as block with nodeblock is an "Overkill".

Beans give you the same thing but without create a node and a block for that node.

Beans is also field-lable, and you can export it with features, you can create your own beans type as you make with nodes.

And the best thing is that you don't need a published node to print a block, you only need a block.

Beans works fine with views and entity-cache, I think it also works with dispaly suit, I'm not sure now.

Please try it and forget all you know about nodeblock.

Oskar

@oskar_calvo I think you are wrong. I guess you didn't try nodeblock. (BTW: the nodeblock module has 22000 reported installations)

@chefnelone, Nodeblock is Drupal 6, Beans is Drupal 7.

I used in drupal 6 nodeblock, but with Bean you don't need to create a nodetype, you define a blocktype, and decide where to print it.

You get the same, or betten with less modules.

I don't care how many people use nodeblock, remember "la mierda tiene que estar deliciosa, un millon de moscas no pueden estar equivocadas".

I agree with @oskar_calvo, why do we need to create several ambiguous node types when we can create block types as well? BTW, Drupal 8 has functionallity similar to Bean in its Core now. It's just more semantic and understandable to have node types for nodes and block types for blocks. Nodeblock was the only solution for D6 where we didn't have Entity API and could attach fields only for node types.

@chefnelone, can you explain why do you think that nodeblock is better? Did you try bean?

Anyway, guys, I think this issue is about wysiwyg and translations - not the "Nodeblock vs Bean" battle ;)

Status:Needs work» Needs review

This patch is a combination of above patches (#57 and #20) and some documentation additions so I could more easily browse to implementations of methods called.

Observations:
- The #pre_render from #20 as element default is needed as such because wysiwig also does define its prerender like that and form API (IMO incorrectly) does not merge in element defaults for array values.
- it has been tested on term descriptions on an install with wysiwyg module + ckeditor as editor. Term descriptions are not fields, so all the code from the former patches that checks for $string['#value'] and then replace $string with $string['#value'] is left as was, but probably had no test coverage.

What does it do:
- It checks if the original string is a formatted string. if so, it makes a text_format form element, otherwise a textarea form element.
- As the text format itself is defined by the original string, the drop down is disabled to prevent changing the format. This can be changed client side, e.g. with firebug, but it is not stored so it is not dangerous.
- The help text about the chosen format is rendered by the element itself (therefore the deletion of the call to _i18n_string_translate_format_help()).
- As before, the normal access checks nicely apply, so if you do not have access to the text format of the original, you won't be able to translate it.

StatusFileSize
new7.88 KB
FAILED: [[SimpleTest]]: [MySQL] 2,091 pass(es), 5 fail(s), and 0 exception(s).
[ View ]

And here is the patch ...

Status:Needs review» Needs work
Issue tags:-block translation, -tinymce wysiwyg

The last submitted patch, 1252144-74-support-wysiwyg.patch, failed testing.

Status:Needs work» Needs review

#75: 1252144-74-support-wysiwyg.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+block translation, +tinymce wysiwyg

The last submitted patch, 1252144-74-support-wysiwyg.patch, failed testing.

Assigned:Unassigned» fietserwin

I'm working on the tests. They need to be adapted to the new situation where there are text_format fields instead of textarea fields.

Assigned:fietserwin» Unassigned
Status:Needs work» Needs review
StatusFileSize
new9.16 KB
PASSED: [[SimpleTest]]: [MySQL] 2,095 pass(es).
[ View ]

Got the tests to pass locally, let's check it again.

I'm using the PHP mode (with php filter)...
It's not work very fine, the php code is not interpreted...

I've <?php print 'Hello World!' ?> and I've <?php print 'Hello World!' ?> in the source code and nothing at the place where it should be printed.

Status:Needs review» Needs work

Status:Needs work» Needs review

You cannot use wysiwyg editors with PHP code. If you have a text format that allows the PHP code filter, you should disable the wysiwyg editor for that filter (both in source and when translating). When you use the wysiwyg module, you can enable/disable the editor per text format. So, IMO this problem has nothing to do with this patch.

Back to needs review. If you disagree, please elaborate why, when and where this patch fails.

Status:Needs review» Needs work

The idea looks good, obviously we need to replace in some cases the textarea with text + format. Some issues with the implementation:
1. We need a different function to translate text + format, otherwise it may clash with some usages of array translations.

function i18n_string_translate($name, $string, $options = array()) {
+  if (is_array($string) && isset($string['value'])) {
+    $string = $string['value'];
+  }
   if (is_array($string)) {
     return i18n_string_translate_list($name, $string, $options);
   }

2. This code could be cleaner, by separting better both types of form control:
$form[$item->get_name()] = array(
....
);

3. When does this happen? Shouldn't we handle it on form validation?. Also not very nice dumping arrays in the watchdog.
+    if (is_array($value)) {
+      if (isset($value['value'])) {
+        $value = $value['value'];
+        $form_state['values']['strings'][$name] = $value;
+      }
+      else {
+        form_set_error("strings][$name", t('Unable to get the translated string value.'));
+        watchdog('locale', 'Unable to get the translated string value, string array is: %string', array('%string' => var_dump($value)), WATCHDOG_WARNING);
+      }
+    }

4. Do we really need that hook_element_info_alter() ? Can't we handle it on form / element 'after build' ?
5. New features do need tests.

Status:Needs work» Needs review

80: 1252144-80-support-wysiwyg.patch queued for re-testing.

#43 kind of worked for me, but as the WYSIWYG format was stripped I got into touble with the display.

However, there is another way with taxonomy: Instead of using the term description field for content that needs to be formatted (as was my case), you can add a new long text field to the taxonomy and then translate that field with the Entity Translation module: the https://drupal.org/project/entity_translation - works like a charm!

Entity translation is still a painful alternative:

- need ET module
- need Title module
- need to re-add translated names of all your terms
- need to redo any views that used term name and replace with new title_field
- this field as a views filter doesn't support select lists and better exposed filters module doesn't handle the ET title field

buyer beware!!

Ideally a workable patch would come out of this and the translated term description field would work with wysiwyg; but in the end.. if you add any other field to your term that you want translated; you will still need to go the ugly route of entity translation.

One other solution to this (at least for term description field) is to go back to D5 days and create a node type to attach to each term. Tag node with the term. Handle translation as usual by translating that node. Use relationships in views/etc to grab the data.

ughh!! but that is D7 and term translation.

Issue summary:View changes
Status:Needs review» Needs work

Issues in #84 still not addressed.

Works the patch #80 for taxonomy term?

Thank you!