So let's say I have a rule that sends an email, and the email body field is generated using PHP evaluation. If I then translate this rule (and leave the field with PHP code untranslated), the body field breaks. It interprets the PHP code as plain text.
It's possible to workaround this problem using PHP eval throughout the rule (using the t() function) and then leave the rule itself untranslated.

I think Rules Internationalization shouldn't touch fields which use PHP evaluation. Or possibly, since a field can be something like this The number is <?php floor($object->number); ?>., it should call the function in Rules that takes care of the content of fields.

Comments

a.ross’s picture

a.ross commented

I found a better workaround. Use the action "Add a variable" to add stuff with PHP evaluation, as that won't be treated as translatable. Then just use the data selector to select this variable in the Rule action that requires it.

tr’s picture

tr commented
Issue summary: View changes
Status: Active » Closed (duplicate)

There is a newer issue that addresses this problem with a patch, see #2168531: Translating of messages that has php code inside

So even though this current issue is older, I'm going to close this as a duplicate and leave the newer one open.