Different solution for TranslateBehavior

[farook-walker]

Loading current translation for associated models should be implemented. Why i can't read translations for current locale in a straightforward way like $page->post->title. I implemented a temporary solution using query formatter, by loading all translations for associated models than extracting translation for current model and assigning translated values for required fields, but it is a tedious and clumsy one and slows the query process down. I think this feature should definitely be added into TranslateBehavior..

[lorenzo]

It is possible. You need, though, to set the table class to a specify locale

$this->Articles->locale('es_es');
$this->Articles->Comments->locale('es_es');

$this->Articles->find()->contain('Comments'); 

[ionas]

You could probably add AppTable.php and specify a default Translatable language there and then add $this->locale($this->defaultLanguage) to beforeFind (of AppTable and/or YourTable.php). I did not test this so I am not sure if beforeFind is run on the contains queries or if there is a more elegant way to set the locale "app wide" per default.

[ADmad]

Use cases like this does make the idea of having an AppTable by default sound appealing.

[lorenzo]

TranslateBehavior is still missing a feature that I never got around to do as I was waiting after finishing the I18n stuff. It should work similar to 2.x as in automatically finding based on the current locale.

[ionas]

I'd still rather set it as per default per Table instead of some global configuration. I do like AppModel, AppEntity and AppController more than global configuration. But maybe I am alone there.

p.s.: AppTable is still possible, you just have to do it.

[robertpustulka]

@ADmad @ionas but while writing plugins you can't depend on AppTable, cause it may not exist or just break your plugin.

I am 👍 for finding locale from your environment or config.

[ionas]

@robertpustulka you can depend on your plugin's AppTable only :(. Yes.

And I do think you just brought up a big reason to include AppController, AppHelper, AppTable and AppEntity into the core; at least until there is a way found to do Convention over Configuration WITHOUT having environment/config settings. Configuring apps aside Debug/Test/Dev/Live/Prod modes simply sucks IMHO.

[dereuromark]

@ionas It doesn't have to be in the "core" ;) In 2.x those were also all just APP classes - and kind of required as such. That would suffice IMO.

[robertpustulka]

@ionas But as plugins should be reusable, I wouldn't set default locale in my plugin :) An actual app using my plugin should take care of this.

[ionas]

Sorry @dereuromark what I meant was the APP Skeleton, not the core.

[ionas]

@robertpustulka yes you would do that in bootstrap and then import that setting in AppTable/AppEntity and overwrite when required/on case by case.

[robertpustulka]

@ionas Which leads to configuration :) You're right that you could set these values depending on table/entity. But IMO locale should fallback to some automagically set default.

[ionas]

@robertpustulka I do agree that you should get the default locale from the environment and then be able to override that in bootstrap.php / app.php but writing to global configs (e.g. defaults) from model domain is somehow weird (Iike a plugin would need to do to set itself to a new correct lang)

[robertpustulka]

@ionas As I understand this, TranslateBehavior (model domain) should depend on I18n, which handles this defaults stuff. There shouldn't be any SoC conflict.

[markstory]

Fixed by #4662