CApplication has the following properties:
But
CWebModule doesn't have them.
CApplication and CWebModule are both the descendants of
CModule.
So, I think that CWebModule can't have a different sourceLanguage from the one that the application has. I don't think that it's necessary to be so, but it's as it is
by design. And the sourceLanguage is virtually assumed to be fixed as "en_us", because the core messages are written in English.
But, you can write Japanese or French (or whatever language) string as "en_us" sourceLanguage.
I usually create my own modules with Japanese messages hard-coded in the source, because I don't think it can be used outside of my country.
echo 'こんにちは、世界 !!';
But if I had written my messages using Yii::t(), then it could be translated to any other language.
echo Yii::t('my_category', 'こんにちは、世界 !!');
You don't have to write it in English like this:
echo Yii::t('my_category', 'Hello, world !!');
You can provide the translation files of various languages:
// messages/es/my_category.php
return array(
'こんにちは、世界 !!' => 'Hola, mundo !!',
);
// messages/ko_kr/my_category.php
return array(
'こんにちは、世界 !!' => '안녕하십니까, 세계 !!',
);
// messages/zh_cn/my_category.php
return array(
'こんにちは、世界 !!' => '你好,世界 !!',
);
And you can even provide an "en_us" translation for it.
// messages/en_us/my_category.php
return array(
'こんにちは、世界 !!' => 'Hello, world !!',
);
1) If I want to use this module of mine, I would not set 'sourceLanguage' (so it defaults to 'en_us') and set 'language' as 'ja' (Japanese) ... That means 'こんにちは、世界 !!' is logically assumed to be written in English, although it is in Japanese in fact. Because the 'ja' translation is missing, the message in the source language (that is in "en_us" logically but "ja" in fact) will be used.
2) If someone in Spain wants to use this module, he would no set 'sourceLanguage' (so it defaults to 'en_us') and set 'language' as 'es' (Spanish). The message will be translated by 'messages/es/my_category.php'. The string 'こんにちは、世界 !!' is assumed to be English in this case, too.
3) If someone in US wants to use this module, he has to set the 'sourceLanguage' as 'ja' (or some virtual language like 'foo'), and has to set 'en_us' as the 'language'. Setting only the latter is not enough, because the translation will not be performed when the 'sourceLanguage' and the 'language' are the same. As for the core messages of the framework, thanks to the lack of translation files for 'en_us', the translation won't happen and the default messages will be used.
I hope it make some sense.
But I would write my source messages in English for the sake of simplicity if I ever want my module to be used world wide.