fix translating validation exceptions

hm, the RulesException is designed to not work that way. However, we want nicely translated and formatted validation errors in the UI, so we should make sure those get translated. The way the RulesException works is bad for that as potx would miss its strings, so in practice they probably won't get translated.

So let's better translate the text before it goes into the exception. I don't see any cause why we shouldn't translate the text before it goes into the exception? Validation-exceptions won't go into the watchdog usually anyway.

So we could
* add a new type of exception, RulesValidationException - which is intended for output and receives translated messages + optionally a form element / parameter for which to show the error?

As this is slight API change, we should do that before the release.

--- includes/faces.inc
+++ includes/faces.inc

This should go to the faces project: http://drupal.org/project/faces

+++ includes/faces.inc
@@ -130,7 +130,8 @@ if (!class_exists('FacesExtendable', FALSE)) {
+      throw new FacesExtendableException(t('There is no method @name for this instance of the class @class.',
+			array('@class' => $class, '@name' => $name)));

make sure to use spaces for indentation, not tabs.

+++ includes/faces.inc
@@ -180,13 +181,14 @@ if (!class_exists('FacesExtendable', FALSE)) {
+        throw new FacesExtendableException(t('The class @class doesn\'t implement the FacesExtenderInterface.',array('@class' => $className)));

missing space after the comma, see the Drupal coding standards: http://drupal.org/coding-standards

+++ includes/rules.upgrade.inc
@@ -574,7 +574,7 @@ function rules_action_drupal_goto_upgrade($element, $target) {
-    drupal_set_message(t("Warning: The 'immediate' option for the page redirect action has been dropped in Rules 2.x."));
+    drupal_set_message(t('Warning: The \'immediate\' option for the page redirect action has been dropped in Rules 2.x.'));

don't use single quotes here, as this may not be handled properly by .pot file generators for text translation. See http://drupal.org/coding-standards#quotes

Remarks apply to multiple locations in your patch.

I'm not sure about that.

This is also involves rules_log(), as exceptions go into the rules log. So if exceptions land translated there, regular log entries would have to do so too. However, that would negatively impact performance as it runs quite some t() calls on strings that are probably never displayed.

Grepping for exceptions in core, core isn't consistent with translating exceptions either. So I don't think there is cause to change this existing and working API now, when we should work towards a stable release.

So let's better translate the text before it goes into the exception. I don't see any cause why we shouldn't translate the text before it goes into the exception? Validation-exceptions won't go into the watchdog usually anyway.

Let's introduce something like a RulesValidationException for validate() that expects a translated exception message and optionally allows bind the exception to a certain parameter. That way we can use it to create form-errors marking the form of the parameter as cause.

@faces:
yes, but we should fix at /project/faces first and then take over the changes in rules.

>I think ALL the current uses of RulesException involves validation, so I don't understand what benefit would come from the residual RulesException.

No, there are other use-cases. RulesExceptions are thrown if something cannot be executed. But you are right, during integrityCheck() the exceptions thrown are basically the same as for validate(). So what about using a translated RulesIntegrityException for both cases while staying with RulesException for everything that involves execution? We could even go and rename it to RulesEvaluationException as I don't think it's used outside for Rules now. (API changes.. :(°°°)

>(BTW, why are tests not running here)
The test bot stopped working for projects with dependencies :/

We need to obey the general plans for error handling here, as I've outlined at #1142852-9: improve erros and Rules evaluation log handling. We certainly need the ability to log errors to watchdog, for which we need the non-translated exception as we have it now.

Patch that splits up RulesException in 4 different exceptions:
* RulesException, abstract mother class (catch all)
* RulesEvaluationException, thrown during Rules execution. Does not use t() in the constructor for logging.
* RulesIntegrityExecption, thrown during configuration and validation, translateable end user UI messages
* RulesDependencyException, thrown if a module is missing during configuration

Not yet heavily tested.

just a slight documentation improvement.

- * An exception for Rules.
+ * A common exception for Rules. This class can be used to catch all exceptions
+ * thrown by Rules.
  */
-class RulesException extends Exception {
+abstract class RulesException extends Exception {}
+
+/**
+ * An exception that is thrown during rules evaluation. Messages are prepared
+ * for log entries (e.g. watchdog()).

The first line of comments should not contain any new-lines, but may exceed 80chars. Fixed that.

Also, I think the dependency exception should extend the integrity-exception, as it is just a special case of it.

re-rolled patch fixing the issues, including some doc improvements.

If the tests are green this is RTBC

thanks committed + added api changes summary to the issue summary.