Hello,
Dealing with translation in form can be tricky. This is the process I used
to do the job, this process might not be suitable for all projects ...
- I use the mgI18nPlugin with "learning_mode" set to true, so all
translations called through the __() function will be automatically added to
the message databases.
- then I reset the form's labels, error messages and translation
catalogue with the swFormExtraPlugin. So all labels and error messages will
have a standard format and a dedicated catalogue
- label : label_name, etc ...
- error : error_message, etc ....
- The last point solve another issue : the mandatory star ;)
By doing so translations will be available in the mgI18nPlugin translation
popup except the one set in a post validator. However if you call this
validator the error will be available in the database... Obviously when you
test an application all the translation should be set in the database
http://rabaix.net/en/articles/2009/07/27/wording-is-not-a-developer-job-part-2
(the
last part)
On Mon, Mar 15, 2010 at 4:08 PM, Tom Boutell <[email protected]> wrote:
> Also, thanks for the suggestion on loading i18n globally in a plugin.
> We've already worked through calling use_helper('I18N') from every
> template, but I guess loading __() globally wouldn't have any
> detrimental effect even if the developer is not expecting it (my main
> reason for not just requiring it be enabled globally as one might do
> in an application).
>
> As others have pointed out, one can just have a never-called function
> with a lot of __() calls just to satisfy an extraction task.
>
> This morning I enhanced my form i18n extractor quite a bit - it gets
> the form labels the same way a form formatter would but without
> actually rendering HTML and regexping it (yuck). And it also gets
> messages from all validators, including pre and post validators. Not
> bad, if you're willing to ensure that all of your forms can be
> instantiated without arguments, at least in a sloppy warning-producing
> way solely for this purpose.
>
> On Sun, Mar 14, 2010 at 4:44 PM, Nicolas Perriault <[email protected]>
> wrote:
> > On Sun, Mar 14, 2010 at 8:43 PM, Tom Boutell <[email protected]> wrote:
> >
> >> Your "throw some __() calls that don't do anything in there" technique
> >> is a useful one which I'll keep in mind for anything I can't resolve
> >> by instantiating and querying and etc. Thanks.
> >
> > Personally and even if I wouldn't recommend this technique as a best
> > practice, I just load the __() helper globally from a configuration
> > class. Example within a plugin configuration class:
> >
> > class myPluginConfiguration extends sfPluginConfiguration
> > {
> > public function initialize()
> > {
> > $this->dispatcher->connect('context.load_factories', array($this,
> > 'listenToLoadFactoriesEvent'));
> > }
> >
> > public function listenToLoadFactoriesEvent(sfEvent $event)
> > {
> > $event->getSubject()->getConfiguration()->loadHelpers(array('I18N'));
> > }
> > }
> >
> > So you can use the __() helper directly in your forms (and controllers
> > btw), and so the i18n:extract task tokenizer will be able to parse
> > form (but you'll have to tweak the extract task class though). It's a
> > bit weird to have this "global" function available, but I gained so
> > much time and brainhealth by doing so that I can't really be ashamed
> > of using it ;)
> >
> > I should add that even if it's especially handy for i18n error
> > messages, it should not be used for help texts or labels; those should
> > be always handled in templates.
> >
> > My 2 cents.
> >
> > ++
> >
> > --
> > Nicolas Perriault
> > http://prendreuncafe.com - http://symfonians.net
> > Mobile: +33 660 92 08 67
> >
> > --
> > If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
> >
> > You received this message because you are subscribed to the Google
> > Groups "symfony developers" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]<symfony-devs%[email protected]>
> > For more options, visit this group at
> > http://groups.google.com/group/symfony-devs?hl=en
> >
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
Thomas Rabaix
http://rabaix.net
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
