Zend Framework

Please categorize/fix as needed.

I've given this issue some thought, but ultimately come back with some questions.

The original intent for the result object was not to provide the message that ultimately gets displayed as part of the UI, but as a more informative message to the developer. This is in the same vein as exceptions messages. Exception messages are never intended to be part of the UI, although I feel its common that some people use them as part of the UI.

Filters and validators are a different subject I think. Their messaging is intended to be used as part of the UI as dictated by their use in Zend_Form, so translations there make alot of sense. The reason Zend_Auth uses words like "identity", "credential" and "ambigious" are because those are the "academic" words that would encompass all use cases. Typically, in a developers application, they would use words that make more sense to their problem: "username", "password", "token", "retinal scan", etc.

Lets round out this discussion. Ideas?

I agree with Ralph on this one. The Zend_Auth exceptions are primarily so you can categorize what type of authentication failure occurred, and then provide feedback (or not) based on that information. As such, it makes most sense for the developer to craft their own message strings and provide translations accordingly.

I have to say that i agree in 50% with you.

I agree that result messages should may be information to the developer instead of end-users, but...

... When developing in my personal case, i feel comfortable getting message codes that message texts, this is because with codes we have the opportunity to do a switch easily to display a UI message.

What i disagree is that, if message texts where implemented they should be able to allow localizacion on them too, i mean actually a developer would have to get the message code, and add a UI message to that doing translation on its own, when most of Zend components have localization integrated on every message template they have.

Now even if it is a message to the developer, it still needs the ability to be translated, remember that even when most developers know english, and program in english, message texts not always are in that language.

My personal opinion is that message localization should be inside the Zend_Auth, to be at least a locale aware class.

Generally I agree.

Still there is one missing point:
A developer has sometimes the need to output a exception text to a user. Maybe this is more the case for Auth than other components.

The thing in this case is that Auth returns exceptions and not error messages. This means that the developer has to translate exception messages which is actually not easily possible. And rethrowing is a bad practice. Also making exceptions translateable just for Zend_Auth introduces several other problems.

See my Translateable Exceptions proposal (http://framework.zend.com/wiki/display/ZFPROP/Translateable+Exceptions+for+ZF+-+Thomas+Weidner) which aims to solve this problem generic for all components at once.

I mean that there are usecases where exceptions are displayed to a user and where they have to be translated or rewritten. And such a feature should not be limited to Zend_Auth.

According to message codes... actually there are no codes for exceptions... the related proposal has been denied. Also something which could be thought of again.

I think we should revisit this when we come to a conclusion on the validity of translating exception message. IMO, exception messages are part of the language and they are intended for the developer only, not the user. I think of exception messages, and auth result messages as part of the overall API, which is in english. Just like the PHP language, the Zend Framework public API, etc.

Please keep an eye out on this proposal in the mean time:

http://framework.zend.com/wiki/display/ZFPROP/Translateable+Exceptions+for+ZF+-+Thomas+Weidner

Once we come to a conclusion on that proposal, which in all honesty might have to wait for 2.0 if we decide there are fundamental changes in the framework that need to occur, we can identify what to do with Zend_Auth result codes.

PS. ha, funny how i was making this message when Thomas linked the same thing!