Forums

curly braces in field values or conflict with Easy Language

emmexx 01 May, 2013
I created an application to create form modules (A, data entered by visitors) based on parameters saved in another form module (B, parameters entered by managers).
Now I'm asked to translate the module to other languages. I can use the CF multilanguage element for fixed parts of forms of type A but I must do it another way for variable parts, text that is loaded from fields in records of form of type B and put inside form A.

To translate the variable text I installed the Easy Language plugin and it works fine.
Almost fine...
The plugin works like the following:
{lang en}english text{/lang}{lang it}testo in italiano{/lang}

So I use this format when I want a multilanguage parameter text in form B.
The problem is that when I edit a record of form B, part of the plugin tags are lost. The previous text becomes:
{lang en}english text{lang it}testo in italiano

That is the closing tag in curly braces is lost.
I suppose this is a problem of CF, probably the content of the record is sanitized before being shown.

Is there a way to prevent that effect?

Thank you
maxx
GreyHead 01 May, 2013
Hi emmexx,

There are a couple of place that this might happen. (a) when the data is saved in the database or (b) when the Show HTML action runs the republisher. In either case it's a side-effect; ChronoForms doesn't deliberately sanitize or change anything like this.

Can you see where the change is taking place?

Bob
emmexx 01 May, 2013
Hi Bob,

the plugin works up to when I edit the parameters record and save it. So I suppose we have a situation of type b.
The following is the result of a Debugger after a db Record Loader:
[presenza_des_1] => 5 giorni (dal 19 al 23 giugno)


I tried the following too:
{lang it}5 giorni (dal 19 al 23 giugno){\/lang}{lang en}5 giorni (dal 19 al 23 giugno){\/lang}


After reloading the record in the form I get:
debugger field
[presenza_des_1] => {lang it}5 giorni (dal 19 al 23 giugno){\/lang}{lang en}5 giorni (dal 19 al 23 giugno){\/lang}


Field value
{lang it}5 giorni (dal 19 al 23 giugno){lang en}5 giorni (dal 19 al 23 giugno)


I don't know what to do.

Thank you
maxx
GreyHead 01 May, 2013
Hi emmexx,

As far as I can tell it is a problem with escaping the \. You might try adding Custom Code actions to loop through the $form->data array and add or remove the {\/ and {/ combinations as needed. There's a PHP array replace function that will probably do it in a couple of lines of code.

Bob
emmexx 01 May, 2013

As far as I can tell it is a problem with escaping the \. You might try adding Custom Code actions to loop through the $form->data array and add or remove the {\/ and {/ combinations as needed. There's a PHP array replace function that will probably do it in a couple of lines of code.



I think I found the problem in a CF function:
libraries/chronoform.php

function curly_replacer($content = '', $data = array(), $exploder = '.', $replace_null = false){
 preg_match_all('/{([^(}|{| )]*?)}/i', $content, $curly_matches);
 if(isset($curly_matches[1]) && !empty($curly_matches[1])){
  foreach($curly_matches[1] as $match){
   $value = $this->get_array_value($data, explode($exploder, $match));
   if(!is_null($value)){
    if(is_array($value)){
     $content = str_replace("{".$match."}", var_export($value, true), $content);
    }else{
     $content = str_replace("{".$match."}", $value, $content);
    }
   }else{
    if($replace_null === true){
     $content = str_replace("{".$match."}", '', $content);
    }
   }
  }
 }
 return $content;
}


I used an online tool to get the result of preg_match_all on the string:
{lang it}foo{/lang}{lang en}foo{/lang}

And the result is:
Array
(
    [0] => Array
        (
            [0] => {/lang}
            [1] => {/lang}
        )
    [1] => Array
        (
            [0] => /lang
            [1] => /lang
        )
)

And if I understand correctly the inner workings of the curly_replacer function, the matched strings are replaced by ''.

I'm not sure that that function is used when a record is reloaded in a form but I suspect it is.

Anyway I'll try your suggestion and add the closing tag as needed before saving the record.

Thank you
maxx
GreyHead 01 May, 2013
Hi emmexx,

That's the ChronoForms republisher that looks for strings in curly brackets and replaces them with form values. You can try turning that off in the Show HTML action (it's the last option on the General Tab). That will show you if it is the cause.

You may be able to fool it by trying this in a Custom Code action before the Show HTML action:
<?php
$form->data['\lang'] = '{\lang}';
?>
I'm not sure if that will work but it might . . .

Bob
emmexx 01 May, 2013

That's the ChronoForms republisher that looks for strings in curly brackets and replaces them with form values. You can try turning that off in the Show HTML action (it's the last option on the General Tab). That will show you if it is the cause.


Disabling curly brackets would wrac havoc in my form! 🙂

You may be able to fool it by trying this in a Custom Code action before the Show HTML action:

<?php
$form->data['\lang'] = '{\lang}';
?>
I'm not sure if that will work but it might . . .



The code you are suggesting fools me, before fooling CF!
I don't understand how that code could work but it could be some of the inner workings of CF.

Anyway I took half of your suggestion and put the following in a Custom Code just before the Show HTML action:

<?php	
 function easyLanguageTag(&$element, $key)
 {	
  //replaces /lang with {/lang} for Easy Language plugin
  $element = str_replace("/lang", "{/lang}", $element);
 }
	
 array_walk($form->data['parameters'], "easyLanguageTag");
?>


And now everything works.
The same Custom Code put at an earlier stage in the loading of the form doesn't work (becasuse of curly_replacer).

Thank you for your precious help
maxx
GreyHead 02 May, 2013
Hi emmexx,

Good to see that you found a solution that works - well done!

The suggestion for disabling curly brackets was only meant to be a temporary debugging test, sorry not to be clearer. And the second suggestion was trying to use the curly replacer to keep the {/lang} tag instead of replacing it.

Bob
emmexx 02 May, 2013

The suggestion for disabling curly brackets was only meant to be a temporary debugging test, sorry not to be clearer.



You were clear. But my form is a little bit complicated and when I disabled the curly brackets I got no useful debugging info. I should have modified other php code only to verify where the problem was.

And the second suggestion was trying to use the curly replacer to keep the {/lang} tag instead of replacing it.



I keep not understanding how that could work but I'll give it a try in a test form.

Anyway I modified my Custom Code in order to get translated header elements too:

<?php	
//put it just before show html action!
//set the mode of the element to View
function easyLanguageTag(&$element, $key)
{	
 $element = str_replace("{/lang }", "{/lang}", $element);
	}
	
 array_walk($form->data['parameters'], "easyLanguageTag");
 $form->form_output = str_replace("{/lang }", "{/lang}", $form->form_output);
?>


Bye
maxx
emmexx 03 May, 2013

Anyway I modified my Custom Code in order to get header elements translated too:



I was overly optimistic about the effect of the code I suggested in my previous post.
It works in a very simple setup. It doesn't work in my production form.

The code that does not seem to work is
$form->form_output = str_replace("{/lang }", "{/lang}", $form->form_output);


I event tried to change the position of the Header element containing the easy language tags and the resulting form is in many cases messed up.

Any suggestion?

Thank you
maxx
emmexx 04 May, 2013

"You were clear. But my form is a little bit complicated and when I disabled the curly brackets I got no useful debugging info. I should have modified other php code only to verify where the problem was." Diabling curly brakets is standard prctice.
--------------------------------------------

NFC Tags



You're right, but I follow the Churchill rule: "However beatiful the strategy, you should occasionally look at the results".
And disabling the curly brackets gave me no debugging information.

Anyway, I found out the problem. The Custom Code Element must be put after the Show Html Element, not before it.

There's still a problem with the Easy Language plugin tags in Email action, the Custom Code doesn't work, I'll use the switch method suggested in this FAQ.

Thank you
maxx
This topic is locked and no more replies can be posted.