ZF-2954: using zend_translate for custom validation message for each validation

Description

Don't know whether I got the topic/summary right, what I mean is the often asked question: "Zend_From offers a translator. However when more then one field uses a certain Validator, there is no way to set up different messages for every field"

One possible solution would be to translate the message and not just the key. So this will be possible:


$validator_email_empty->setMessage("invalid_email_empty");
$validator_name_empty->setMessage("invalid_name_empty");

and sql or whatever (remember, this will be for several languages!): invalid_email_empty => we do need your email address! invalid_name_empty => name field cannot be empty

Index: Validate/Abstract.php
===================================================================
--- Validate/Abstract.php   (revision 9039)
+++ Validate/Abstract.php   (working copy)
@@ -191,7 +195,10 @@
         $message = $this->_messageTemplates[$messageKey];
 
         if (null !== ($translator = $this->getTranslator())) {
-            if ($translator->isTranslated($messageKey)) {
+            if ($translator->isTranslated($message)) {
+                $message = $translator->translate($message);
+            }
+            elseif ($translator->isTranslated($messageKey)) {
                 $message = $translator->translate($messageKey);
             }
         }

now, before someone has the idea to do: ``` just think of Zend_Validate_Between with %min% and %max% in the message

Not sure whether I got the right approach to this, but for me it's working just fine!

In my sql I have a generic "notEmpty" => "this field is required" and "username_invalid_empty" => "you have to enter a username" So I get the later message for username and the first one for all the other fields - in all required languages

Comments

Just two comments on this:

*) actually there is a proposal written which makes it possible to translate exceptions. It would not make sense to double the same implementation in multiple components.

*) %xxx% is not a parameter for translations.... this would not work... the seperator have to be changed to work with translations to $s notation

1) what proposal? the only one I could find that is remotly related is http://framework.zend.com/wiki/display/… But this is the one I want to fix ;-)

2) This is taken from sql of my current project (key, english, german): password_validators_stringLengthTooLong - longer than %max% characters - länger als %max% Zeichen password_validators_stringLengthTooShort - shorter than %min% characters - Mindestens %min% Zeichen

It works fine with the solution I described,

There is another proposal about generic exception handling.

And related to paramters: There is only one handling of parameters when using internationalisation... $s... or %1$s when you have multiple one. All other ways of parameters are not handled by translation.

So the problem is when someone uses the way which only works for Validate he gets problem when he uses the same syntax in other classes.

The only thing I declare is that translation has to be the same in every component, and not that every component integrates his own way use doing this.

agreed, this is more of a hotfix / tempfix if the proposal you are talking about is coming out anytime soon this can be closed/removed completly

I'm gonna use this until there is another solution for the problem and direct people who are asking about internationalisation of validation messages here with the notice to read all comments :-)

It's no problem to extend the core class as shown above and use the own extended class until a official way has been integrated.

But anyone doing this has to be aware of possible differences between self implemented way and the official one.

As I am the "master of desaster" for all translation and internationalization themes in ZF I am always aware of such themes... if there are any questions don't be shy to ask in the mailing list.

Keep in mind to extend the core class and not to rewrite it... otherwise you will have problems with any new release of ZF ;-)

And as already said, before we will integrate this into the core several other problems and issues have to be thought of to have a complete solution and not only a partitial one.

Please categorize/fix as needed.

Reassigning to Matthew for evaluation.

Functionality added in trunk and 1.6 release branch.

Updating for the 1.6.0 release.