Re: Re: QuickForm2: messages and translations

Hi Christian, On 18.05.2011 9:54, Christian Weiske wrote:

Some of the QF2 elements (currently Date and InputFile) have built-in translatable messages (weekdays and months lists and upload errors, respectively). I'd really like to have some feedback (especially from Christian) on the implementation, this will be useful for custom elements as well, so should be well designed. A couple of questions Bertrand raised: 1) Is get() a good enough method name? Won't it lead to name conflicts in MessageProvider implementations?

That depends on the message provider implementation. If it's a class with the single task of translating messages, get() is fine, maybe even "->_()" like the gettext function is called. If the class does several things, get() is obviously not the correct way.

Yes, that part is understandable. The question is: how probable is a class that will do several things at once? I suspect message providers will be backed by some existing translation / locale package. These packages tend to follow the Factory pattern (see PEAR::Translation2, PEAR::I18Nv2) and it is hard to create a subclass implementing HTML_QuickForm2_MessageProvider. Proxy is much easier.

By the way, this reminds me of specifying a callback instead of the message provider object - the method naming problem does not exist there.

I think this will only work with PHP 5.3 and closures, as callback will need to keep some state (i.e. messages it is going to return). You definitely can instantiate an object and pass its method as a callback, but then why not pass the whole object instead?

2) Is it OK that get() can return an array of messages rather than a single message? Of course, if it can only return strings, we'll need 12 get() calls in a loop in Date element for getting the month names.

I do think so. QF2 could even provide a proxy provider for simple message providers that don't accept multiple translation requests at once, while one can always supply a sophisticated one.

OK, lets keep it that way, then. I tweaked the implementation a bit and added some PHPDoc, will probably add another implementation that will allow explicitly setting messages for a specific element and falling back to Default provider if message is missing.