don't agree on this last statement:
> So I dont really see this as problem, more as benefit for users so
> they dont have to learn new things.
(first: my intention wasn't to name problems, I just wanted to figure
out the "official" opinion regarding my questions. As I'm trying to
define some standards for my employers ZF-projects I also wanted to
get some feedback regarding the current best practice for translations)
ZF is providing a collection of PHP-classes, it's currently becoming
mature and it is directly or indirectly telling people how to write
their code. There are already lots of best practice examples for
translations in ZF-projects out there, none of them really made me
enthusiastic.
The translate()-ViewHelper is adding much "overhead" to ViewScripts
in multilingual projects. Code like
<h1><?= _('Hello') ?></h1>
is ways "lighter" than
<h1><?= $this->translate('Hello') ?></h1>
- at least if you imagine more than 5 words / phrases to be translated
on a single page. My personal résumé of this discussion (for those who
care) is as follows:
* I'm not gonna go with the translate()-ViewHelper, there would be
more translation code than Text and HTML together in most of my
ViewScripts.
* I like my very own _()-ViewHelper as shown before - and in my own
projects I don't have to be that nitpicky. My//.php and a My__-class
with a _()-function would be fine - and it just works.
* As __('Hello') looks far better than $this->_('Hello') and as I mostly
need to use translated text in all MVC-components I'll nonetheless
forget about my nice ViewHelper and use a global function instead,
similar to the solution mentioned by "The WRS" in "his" fork of this
thread
* I'm looking forward to the day when ZF will define namespace-support
part of it's minimum requirements. Things could become better... if
they don't get worse, like it happened to PEAR since PHP5. Backward
compatibility is an awful thing ZF didn't have to face right now :p
Cheers,
Thomas
Thomas Weidner schrieb:
> Thomas,
>
> this was the reason why I did not create the "_"-Helper.
> We as core developer can not violate the ZF coding convention.
>
> I heard people where this works, and others where it does not.
> Generally, parsing for translate() instead of _() is a 2 klick option in
> poEdit.
> And changing existing code from _() to translate() is also a 2 klick
> option in and IDE I know.
>
> So I dont really see this as problem, more as benefit for users so they
> dont have to learn new things.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
没有评论:
发表评论