I’ve read (read: scanned ) over the localization docs and the related class details, but something just isn’t quite making sense to me. If I’m reading correctly (and I’m kinda hoping that I’m not), if you use either CPhpMessageSource or CGetTextMessageSource, the messages are stored in key/value pairs, therefore lookup should be something similar to Yii::t([context], [key]). However, if you use CDbMessageSource, the key turns into the full source string. In this case, the source string used in the Yii::t() call and the content of the source table are redundant.
Am I simply misunderstanding things here, or is this by design? If by design, out of curiosity, why the change in design between fs and db lookups?
Thanks for the reply. I figured that it would be like that. My issue with the solution sample was that I wasn’t overly partial to the redundancy between the string used in PHP in the Yii::t() call and the database table. It seemed quite error prone to me and could potentially be rather difficult to debug inconsistencies between the PHP source and database content.
What I ended up doing was only storing loc keys in the SourceMessage table. So, here’s what my tables look like:
id | language | translation
...|..........|.................
1 | ru | Где моя собака?
1 | en | Where is my dog?
...|..........|.................
I’ve forced message translation, so when source language is equal to the current language, it still does the lookup. I’ll be caching the loc results, so extra overhead in forcing the lookup should be minimal.
In this case I think the first table is redundant. I didn’t understand the Yii-translation-things until I found this thread and now I am sure it’s better to do translations by myself - It’s easier for me to create a new function that does exactly what I need than to try to learn functions of Yii… Mainly when they are so badly documented, without examples. I do not consider following page to be a manual or explanation: