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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jose Reyero’s picture

Title: Wysiwyg Javascripts don't get loaded for block translations » Support 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?)

anou’s picture

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 :-)

skks’s picture

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.

rOnnie974’s picture

I'm also looking for any solution…

chymz’s picture

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


/*
 * 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/>';
            }
        }
    }
}

skks’s picture

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.

Valdars’s picture

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.

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']);
    }
  }
}
DuaelFr’s picture

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

Elvin - Albania Drupal Developer’s picture

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

DuaelFr’s picture

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

abasso’s picture

Just what I needed, thanks!

nikosnikos’s picture

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.

SaxxIng’s picture

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

mineaeliza’s picture

thank you! it worked for me too!

nikosnikos’s picture

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.

nikosnikos’s picture

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.

dimitriseng’s picture

Version: 7.x-1.0-rc3 » 7.x-1.4
Status: Needs work » Needs review
FileSize
2.99 KB

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.

dimitriseng’s picture

Status: Needs work » Needs review
FileSize
2.99 KB

Status: Needs review » Needs work

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

mpp’s picture

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

gge’s picture

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

f4o’s picture

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

dimitriseng’s picture

@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.

f4o’s picture

@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']);
    }
  }
}
dimitriseng’s picture

@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.

Jose Reyero’s picture

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?

dimitriseng’s picture

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.

kelvincool’s picture

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.

dimitriseng’s picture

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

zilverdistel’s picture

Version: 7.x-1.5 » 7.x-1.x-dev
Component: Blocks » Strings
Status: Needs work » Needs review
FileSize
3.86 KB

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
Jose Reyero’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +block translation, +tinymce wysiwyg
kennedyabitbol’s picture

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) + ']]';

kennedyabitbol’s picture

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.

Anonymous’s picture

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

blackandcode’s picture

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

blackandcode’s picture

FileSize
853 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...

Nicolas Bouteille’s picture

#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 !

tierso’s picture

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

lmeurs’s picture

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!

/**
 * 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']);
    }
  }
}
mineaeliza’s picture

Thanks lmeurs! Your solution worked great for me!

tierso’s picture

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

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

tierso’s picture

Status: Needs review » Needs work
Issue tags: +block translation, +tinymce wysiwyg
castawaybcn’s picture

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

lor’s picture

+1 for #43.
Thanks lmeurs and all!

pipicom’s picture

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

chefnelone’s picture

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.

titouille’s picture

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.

lmeurs’s picture

Hi titouille,

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

if (isset($form['strings']['all'])) {
  // First foreach block goes here.
}
titouille’s picture

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 :


    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

dandolino’s picture

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

almul0’s picture

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:

$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.

almul0’s picture

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.

barduck007’s picture

@#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"];

oskar_calvo’s picture

@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

francescoNemesi’s picture

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

tedbow’s picture

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.

almul0’s picture

#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

almul0’s picture

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

oskar_calvo’s picture

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

chefnelone’s picture

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

oskar_calvo’s picture

@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

dimitriseng’s picture

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.

chefnelone’s picture

@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.

oskar_calvo’s picture

@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

chefnelone’s picture

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

oskar_calvo’s picture

@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".

xumepadismal’s picture

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 ;)

fietserwin’s picture

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.

fietserwin’s picture

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.

Echofive’s picture

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.

fietserwin’s picture

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.

fietserwin’s picture

Assigned: fietserwin » Unassigned
Status: Needs work » Needs review
FileSize
9.16 KB

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

Echofive’s picture

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.

Echofive’s picture

Status: Needs review » Needs work
fietserwin’s picture

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.

Jose Reyero’s picture

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.

harrybosch’s picture

Status: Needs work » Needs review
vegardjo’s picture

#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!

liquidcms’s picture

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!!

liquidcms’s picture

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.

Jose Reyero’s picture

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

Issues in #84 still not addressed.

ballester’s picture

Works the patch #80 for taxonomy term?

Thank you!

robined’s picture

Are people now just accepting patch from #80?

Nicolas Bouteille’s picture

I guess #80 can be used by people who need a quick fix but issues from #84 should still be addressed before committing...

spidersilk’s picture

Just a quick note to say that the patch from #80 appears to have worked like a charm for the site I'm currently working on. Thanks, fietserwin!

chanac_hares’s picture

Hi,

Patch #43 works for me too.
It's a better solution than the patch.

Thx

jpvosmeer’s picture

Solution #80 works for our project for showing the Wysiwyg in translation blocks.

NIKS_Artreaktor’s picture

It is already 1.12 version... But Patch is not there. Why - Patch not working?
It is very hard to use this patch every time.
Of course, it is better to use #43.

Can patch already be in final version of module?

Tyler the Creator’s picture

#80 works for translating blocks with the WYSIWYG, but it adds text formats to Views translations, which ends up stopping you from being able to save the view's translations.

mlanth’s picture

#80 works for translating blocks with the WYSIWYG, but it adds text formats to Views translations, which ends up stopping you from being able to save the view's translations.

Found a possible solution. You can check first to see if the format provided exists within the available formats for that user/site, and if it is not in the list, NULL format. Doing this will set the form item type to textarea instead of text_format.

Sebastian_Campanella’s picture

Hello I did some changes to the solutions #43.

This solutions work fine with Blocks and taxonomy but Didn't work on regional/translate/translate.

Here my solution. I hope that It can help someone.

function yourmodulename_form_alter(&$form, &$form_state, $form_id) 
{
    /**
     * Implements hook_form_alter().
     */
            
     if ($form_id=='i18n_string_locale_translate_edit_form' ) 
        {
        
         // Loop all i18n_string.
                    $languages = locale_language_list('name');
                    foreach ($languages as $lang => $fieldl) 
                        { 
                            foreach ($form['translations'] as $name => $field) 
                                 {
                                     if (preg_match("/".$lang."/i", $name)) 
                                         {
                                             $form['translations'][$lang]['#type'] = 'text_format';
                                             $form['translations']['format_help']["#markup"]= '<br />';
                                         }
                             }   
                    }
                    // Add submit function.
            $form['#submit'] = array_merge(array('_yourmodulename_form_submit') , $form['#submit']);
         
        }
    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('_yourmodulename_form_submit') , $form['#submit']);
      }
}

function _yourmodulename_form_submit($form, &$form_state) {
     echo "<pre>";var_dump($form_state);echo "</pre>";
     if ($form_state["build_info"]["form_id"]=='i18n_string_locale_translate_edit_form' ) 
        {
            $languages = locale_language_list('name');
                           foreach ($languages as $lang => $fieldl) 
                               { 
                                   foreach ($form_state['values']['translations'] as $name => $field) 
                                        {
                                            if (preg_match("/".$lang."/i", $name)) 
                                                {
                                                    unset($form_state['values']['translations'][$lang]['format']);
                                                }
                                    }   
                           }
        }
     
     
     
     
     
   // Remove wysiwyg format because i18n cant handle it.
   if ($form_state["build_info"]["form_id"]=='i18n_string_translate_page_form' ) {
            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']);
        }
      }
    }
}
Tyler the Creator’s picture

Status: Needs work » Needs review
FileSize
9.32 KB

Patch at #98 had malformed problems. Can someone please review this new patch version?

Ruichao’s picture

#101 works great for me

infiniteluke’s picture

#101 worked great for me in regards to block translations

ea2391’s picture

#101 works great for me too, thanks!

anrikun’s picture

Status: Needs review » Reviewed & tested by the community

#101 works for me too, thanks!

LIQUID VISUAL’s picture

Will #101 be committed to a module?

joco_sp’s picture

+1 for #101

sistro’s picture

#101 works for me too with CKEditor Module

Jose Reyero’s picture

The main concern for this module right now is not really new features but stability, keep working existing sites, that are a lot.

So I would be more worried actually about whether the module still works without Wysiwyg with different input formats. Could someone please test that part?

Another question: is it easy enough to disable the new feature and keep the old behavior?

mlhyyl’s picture

#101 works for me too, thanks!

f0ns’s picture

Thanks, patch #101 works great!

Stevel’s picture

+++ b/i18n_string/i18n_string.module
@@ -259,6 +259,34 @@ function i18n_string_locale_translate_import_form_submit($form, &$form_state) {
+ * We need to do this on the element info level as wysiwyg also does so and form
+ * API (incorrectly) does not merge in the defaults for values that are arrays.
+ */
+function i18n_string_element_info_alter(&$types) {

If there's a bug in Form API that we're working around, this comment should refer to the corresponding issue, so that it's possible to track whether the bug is corrected and this function can be removed again.

Anybody’s picture

The patch has been RTBC 10 month ago. Could we please get this into the next release?

I did not set up the priority because it fits, but a module maintainer should give this patch some love and commit it :)

Jose Reyero’s picture

Status: Reviewed & tested by the community » Needs review

@Anybody,
Yes, 10 months without questions in #109 being replied to.

joseph.olstad’s picture

@Jose Reyero and @Anybody

without answering #109 I am just re-uploading the previous patch in #101 by @Tyler Pepper due to recent testbot changes it needs a reroll.

Rerolling #101

joseph.olstad’s picture

Ok, the latest patch passes the newly fixed simpletests.

Can someone please answer the Jose question from #109 ?

So I would be more worried actually about whether the module still works without Wysiwyg with different input formats. Could someone please test that part?

Another question: is it easy enough to disable the new feature and keep the old behavior?

Once these two questions are answered we will commit this patch to dev.

Thanks everyone for your hard work.

hkirsman’s picture

1. Not sure if this is the right test case but I could choose different profiles during block translation (with and without wysiwyg)
2. What do you mean disable the feature? Disable wysiwyg for translations only? That would not make sense.

Anyways, I tested latest patch and it works fine for me. I'll put it on live environment.

Thanks!

Anybody’s picture

Status: Needs review » Reviewed & tested by the community

@joseph.olstad (#115 / #116): I tried that and yes it works for me. Furthermore I checked the code and I couldn't find any reason why it should not work. Settings this RTBC. If course further feedback is welcome.

Thank you all very much!

joseph.olstad’s picture

Hi @Anybody, so you're confirming that you tested with and without a wysiwyg text format and it works. as per #109 and #116. Cool thanks.

Looks good.

c4ilus’s picture

Hello,

Thanks for this patch :)

One little thing we're observing though: It does load the CKEditor fine apparently, but the WYSIWYG editor stays almost collapsed (its height stays too small).

That seems to be due to the fact that the translation form sets #rows to 1 for the textarea in the following file: www/sites/all/modules/contrib/i18n/i18n_string/i18n_string.pages.inc, more precisely in the function i18n_string_translate_page_form_strings():

'#rows' => $disabled ? 1 : min(ceil(str_word_count($default_value) / 12), 10),

Changing this value does the trick. But i still didn't find the cleanest way to fix the thing.

Any thoughts on this?

PS: We are using i18n v1.14, Ckeditor v1.17

TwoD’s picture

@c4ilus. That's a separate issue and I'm currently working on improving the minimum-height detection in Wysiwyg.
Will probably be the last change to get in before the next release so you shouldn't have to wait long.
Until then you can force a starting height for your editor of choice by implementing hook_wysiwyg_editor_settings_alter().

pacproduct’s picture

@TwoD I guess what you said is not applicable if we're not using wysiwyg but ckeditor?

TwoD’s picture

@pacproduct, correct. I don't know how/if ckeditor.module calculates the initial height, but I would guess you can use their equivalent of the same hook to do the same override.

c4ilus’s picture

@TwoD, thanks for you answer. There is a hook_ckeditor_default_settings_alter(), I will test this.

joseph.olstad’s picture

Status: Reviewed & tested by the community » Fixed

committed to 7.x-1.x-dev branch , thanks for everyones reviews and patches.

No immediate plans for a new tag , so it'll be in 7.x-1.x-dev branch for now.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.