If in my application I had my source language, and several target languages.
And in the DB I had one table per language and also I had its corresponding AR model on Yii (e.g. tbl_model -> model.php, table_model_de -> modelDe.php, tbl_model_jp -> modelJp.php).
And I set and API like $model->getLocalization($targetLang);
And that code internally do something like $localizedModel::model()->findByPk($this->id);
Should be noted that Yii::app()->language; will rule the model that’s going to be put inside $localizedModel; (that logic its inside the custom API “$model->getLanguage();”)
What would happen if there isn’t yet a localization for some of the target languages? let’s say not everything is going to be translated to every languages.
Can we use the model on the source language instead as a default? or… will the site break?
The second would happen.
The only solution I can think of, is to create EMPTY models for EVERY possible value of target language. So, if we handle 20 languages site-wide, and some models are only going to be translated to 2 languages, then we would have to create those 2 respective tables->models, and then 18 empty table->models so that the app don’t throw error when it tries to query them.
I don’t know if it’s a standard practice to have such language specific tables and models in multi-language app …
But even with those language specific models, I would rather want my app to be stopped by a typo, or by my coding error in general. Otherwise I would have great difficulties in debugging my app. I think that selecting a default value should be done somewhere else, not in exception handling.
That’s a pretty tiny thing, useless for the purpose of serious localization.
To finalize this, and in brief, I’d say it all comes down to setting up several tbl_table -> tbl_table_“lang” tables, or just one tbl_table -> tbl_table_translations configuration, and then setting up the rest.
First suits for better DB organization, while second is handier for faster setting up if one doesn’t mind having a pretty big translations table.
I don’t know the size of your app but t sounds a bit like “premature optimization” to me. But in case that you really have millions of messages translated into a lot of different languages you could try to extend CDbMessageSource and rewrite the parts that load the messages to make use of multiple tables instead of one. That would still be better than using your first approach which feels way too hacky.
I really though I was doing the standard thing when using (either one, or several) tables for localization content.
I don’t think CDBMessageSource would be a smart choice for translating content that would otherwise be stored on models, because It is best suited for string translations, and not the wide nature of content that is found within models (e.g. longer text, several fields, DB managenment). Even if your app is tiny. I think it depends on whether are you translating just strings, or full models…