Monday, June 1, 2009

Re: Feedback from TranslateBehavior creator needed

I don't think that beforeFind is a good place to set the locale field,
because when I moved on with i18n'ing my App and tried to do that
stuff:

$pages = $this->ArticleVersion->ArticlePage->find('all',
array( 'conditions' => array
( 'ArticlePage.article_version_id'=> $article_version_id ),
'order' => 'ArticlePage.id')
);

ArticlePage seemed to have string in a locale field and no translation
problem occured once again. Moving
$this->locale = Configure::read('App.locales'); //i18n +
TranslateBehavior
from beforeFind to __contruct did the trick.

Does it have something to do with model chain?

On 1 Cze, 12:38, Grzegorz Pawlik <GrzegorzPaw...@gmail.com> wrote:
> Ok, now I'm even more confused than before ;) So I'll keep nagging
> You.
>
> Question: Why App.locales is better place for locales? I get it why
> Config.language is a bad place. But is App.locales because there's
> some convention I don't know about? Or maybe just Your ideaof place to
> store this stuff?
>
> Now I did sth. like this:
> 1. in bootstrap:
> Configure::write('App.locales', array('pol', 'eng'));
> 2. in AppController::beforeFilter where I handle lang changes I've
> added sth like this:
>       Configure::write('App.locales',
>                         array_unique(
>                            array_merge(Configure::read('App.locales'),
>                                        array(Configure::read
> ('Config.language') )
>                                        )
>                                      )
>                         );
> It's not to elegant but does what I need to be done: App.locales is an
> array for sure, firs locale in App.localse array is the same as
> Config.language (language which is current application language)
> 3. in AppModel::beforeFilter:
>    function beforeFind($queryData) {
>       $this->locale = Configure::read('App.locales');
>       return parent::beforeFind($queryData);
>    }
>
> And it seems to work for me. I realize that getting values for
> original fields when no translation is present is not covered by any
> test. And there is some possibility that after next core update it
> will stop working. In that case I'll admit that making a shell that
> reads original fields and writes it in i18n table is a good option.
> We don't use any phing to handle automatic installation for now, so my
> teammates will just forget to do that ;)
>
> > In AppModel::beforeFind() would be useful to check
>
> > $this->Behaviors->attached('Translate') &&
> > $this->Behaviors->enabled('Translate')
>
> Can You tell me why I should do that?
>
> O n 31 Maj, 13:41, "jitka (poLK)" <slunii...@gmail.com> wrote:
>
> > In AppModel::beforeFind() would be useful to check
>
> > $this->Behaviors->attached('Translate') &&
> > $this->Behaviors->enabled('Translate')
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to cake-php+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

No comments: