Could you just add some information regarding the database structure you use?
In your original extension you describe using 2 tables (one with the main language fields and one with all other languages), but I get the idea youāre using all languages (including the fallback one) in the NewsLang table and only general (non-translatable) information (I assume) in the News table.
No, Iām still using the same database structure (all attributes in the main table, plus translatable attributes in a separate table).
The reason is that it makes it a lot easier to handle missing translations. Having a default or main language allows you to easily fall back to that language in case a translation doesnāt exist, without having to make another query.
Also, in my experience it matches the way most multilingual sites work. They might start as single language sites, or maybe already plan to be multilingual, but almost always they start entering content in the main language, and translations are added afterwards.
Thanks for your fast reply. Would there be any way to adapt your behaviour to allow my kind of db scheme? (one table for non-translatable stuff, the other for all languages)
I havenāt tried, but CActiveDataProvider takes a CDbCriteria object as a parameter. So, if you pass it a criteria object that selects also the related language tables (using āwithā or āscopesā, what you prefer) then it all should work. What I mean is that you should pass CActiveDataProvider the same criteria that you pass to a findAll() call in order to get the translations.
The behavior Iām using expects the main model to have the main attributes defined, so that you can call $news->title, and get the title in the current language. But you could define these placeholder attributes directly in the model, instead of the database. So, in your News model, youād define the attributes:
public $title;
public $intro;
public $content;
...
This would allow you to continue using $news->title and get the translated title, even if the title field doesnāt exist in the news table.
But doing this means you wonāt have the fallback value. If the title translated in the current language does not exist you will get a blank titleā¦
If I understand correctly, I could fill those attributes up with the current language first, check if theyāre empty and use a fallback language when necessary. Is there any drawback to this method (except for the extra query)?
I guess it would be better to query both languages at the same time (current and fallback) - and have the code figure out which one to use - or using a query that will select the right values at once?
Something like:
SELECT o.id
, o.type
, o.code
, o.position
, ifnull(t.name,d.name) name
, ifnull(t.description,d.description) description
FROM base_material o
INNER JOIN base_material_i18n d
ON ( o.id=d.base_material_id)
LEFT OUTER JOIN base_material_i18n t
ON ( d.base_material_id=t.base_material_id AND t.localization_id='nl' )
WHERE d.localization_id='en'
I donāt think I follow you. You could make a query like that, but the purpose of all this was to avoid having to do it. Just by declaring relations and using a behavior you should be able to get the data in the right language.
What I was trying to say is that if you donāt want to have the name and description attributes on the main table, you donāt have to. You can declare them as public properties of your model, and let the behavior populate them with the right data coming from the translations table.
But I think you are right in that you could get current and fallback languages in the same query. Iād try to define a relation with the i18n table like this:
'i18n' => array(self::HAS_MANY, 'ModelLang', 'model_id', 'on'=>"i18n.lang_id='".Yii::app()->language."' OR i18n.lang_id='".Yii::app()->params['defaultLanguage']."'", 'index'=>'lang_id'),
Then, in the behaviorās afterFind() method, you would check for those translations, and set the main model attribute to either of the two (the current language if it exists, the fallback otherwise).
Sorry, I made a mistake in my example. In Section model, the ālocalizedā scope should use the relation āi18nSectionā, not āi18nā, since thatās the relation name we have defined in the model. (You can use whatever name you want for the relation, just make sure you use the same name in the scope).
//Section.php
public function localized() {
$this->getDbCriteria()->mergeWith(array(
'with'=>'i18nSection',
));
return $this;
}
Thanks for your fast reply iāll try it. should i create two table for each model. like news for News model and news_lang for NewsLang model. sorry iām new bie
You should create rules for those attributes, as if they were attributes from the model itself. Better if you use params instead of hardcoding them, something like:
You probably want to add a __isset magic overload as well:
public function __isset($name){
if (! parent::__isset($name)) {
return ($this->hasLangAttribute($name));
} else {
return true;
}
}
I havenāt tested it yet, but something along those lines will do.
I also have suggestions for better names for relName1 and relName2: localizedRelation and multilangRelation
As a final thought, the point where you create $this->langForeignKey from $owner->tableName() is broken if tableName returns a string containing the database name (e.g. āmydb.productsā)
You can replace
$owner->tableName()
with
array_pop(explode('.',$owner->tableName()))
to achieve that extra compatibility.
But those are all small points. All in all, this multilang stuff is really useful.
Iām using the MultilingualBehaviour, and itās working fine in an example I created. The user gets to choose in wich language wants to display the sections and posts related, and it gets the translation correctly.
But my question is how I change the Models and Controllers of the Posts and Section (in the example) to be able to introduce all the files in the diferent lenguages in the Add and Update Form?
Using the previous MultilingualActiveRecord class, by defining the localizedAttributes, languages, etc. it was correctly displayed all the language fields on the form viewā¦
Can you show us the code in order to achieve that?
Hi, itās looking in the Post model because thatās what weāre after, in āmultilangā mode: to make appear the attributes of PostLang model as if they were attributes of Post, for easier handling (like title_es, title_de, etc).
Probably the problem is that you are not loading your model in multilang mode. In my controllers I use this modified loadModel():
public function loadModel($id, $ml=false) {
if ($ml) {
$model = News::model()->with('multilang')->findByPk((int) $id);
} else {
$model = News::model()->findByPk((int) $id);
}
if ($model === null)
throw new CHttpException(404, 'The requested page does not exist.');
return $model;
}
Then in my update action I load the model like this:
public function actionUpdate($id) {
$model = $this->loadModel($id, true);
...
}