@Tom: Sorry for hijacking this thread with this message (just this once): do you still need a translator for Apostrophe into German?
Daniel On 15.03.2010, at 17:12, Tom Boutell wrote: > Thanks! mgl18nPlugin looks useful and I think i get how it's supposed > to be used... but it would benefit a lot from a summary in the > package.xml and an introduction in the README. > > You're inspiring me to share my form message extractor task soon, it's > working well enough at this point that if folks are happy with the > outcome of the first apostrophePlugin translations based on it, then I > should probably release it in some form. > > On Mon, Mar 15, 2010 at 10:58 AM, Thomas Rabaix <[email protected]> > wrote: >> 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] >>>> 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] >>> 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 >> > > > > -- > 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] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en -- 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
