Posted 07 February 2013 - 04:22 PM
the brand new module I have installed in my app, uses a different sourceLanguage than my app. Hopefully (and as it was built with i8n in mind), this module comes with a set of message files that includes the one I need.
Question : how to get the module to use the appropriate language file ?
Thanks for your help.
Posted 09 February 2013 - 06:48 AM
... I mean there are plenty of modules to download from the extension section, and I can't believe the situation where module sourceLanguage differs from app sourceLanguages never occured.
If for instance, in the main webApp, we have :
echo Yii::t('app','modifier'); // sourceLanguage = fr (French)
...and in the module downloaded and installed in the webApp we have
echo Yii::t('moduleCategory','delete this stuff'); // sourceLanguage = en
Assuming that the module does provide a translation file for french, how is it possible to use it so the module displays french strings ?
There must be an easy way but I didn't found it .... so any help is appreciated.
Posted 20 February 2013 - 04:05 AM
I can imagine only 3 reasons :
- this question is stupid, it makes no sense, it can't be understood by a human being, it is not event spelled correctly...
- the reply to this question is so obvious that noone wants to loose time to post it
- this question adresses a problem with no solution in Yii (yet)
So ? which one do you choose ?
Posted 25 March 2013 - 10:28 AM
So it should never happen.
That it can happen, though, is interesting.
Then again, I don't know (or care) much about neither modules nor I18N.
Posted 25 March 2013 - 12:10 PM
Could you please define what you mean by "default source language". Is it the source language of the Yii core ? ... if yes, do you mean that I should always use english as sourceLanguage for my webapps ? ...and then create french message file ?
@Rvr101 : yes but not only modules, also to extensions, or any thrid party component...
Posted 25 March 2013 - 12:26 PM
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.
Posted 25 March 2013 - 03:12 PM
yes, your explanation is very clear and actually the 3 uses cases are helpful to understand how to use 'sourceLanguage' and 'Language' configuration settings in Yii.
What I notice is that the definition of these 2 parameters in the Yii tutorial is, let's says, too simple, in particular to handle cases like the ones you presented.
The Yii tutorial says that :
It is obiouvsly not true for the first example, where you don't set the 'sourceLanguage' so it is assumed to be 'en_us' when in fact it is 'ja'.
Then of course the third example is even more obvious as the 'sourceLanguage' is set to 'ja' or to an imaginary language 'foo', when it should be in fact 'en_us'... and this is just to force Yii to perform translation to 'ja' (the language that your module uses).
Again, the solution you provide is working fine, but in my opinion this looks like a trick, a hack or anyway far from the tutorial simple definition of what 'sourceLanguage' is.
One solution would be to define a "category sourceLanguage map" in the configuration file that would map a translation category, with the actual source language used by this category. For instance, if your module uses category 'softark', and if I want to use it in my own webapp,(fr) I would write in the configuration file :
'sourceLanguage' => 'fr', // the 'real' source language 'language' => 'fr', // the 'real' target language 'categorySourceLanguage' => array( 'softark' => 'ja' // the 'real' source language of your module ),
With this map, Yii::t() would be able to translate any string from your module ....
echo Yii::t('softark','こんにちは、世界 !!');
... into the target language : french (of course, if you provide a french message file).In my opinion this would be much more "clean" than playing with imaginary 'foo' language
Anyway, this is just an idea....
Again thank your very much for your explanation.
Posted 26 March 2013 - 05:38 AM
I don't think it would help because the sourceLanguage applies to the whole webapp (it is member of CApplication) and not to a module, so the 3 uses cases softark presented are still valid and you'll have to play with sourceLanguage/language values again.
Apart from the 'category source language' map above, another solution would be to not use t() as a static method, but (for instance) as a member of CComponent. Of course sourceLanguage would also become member of CComponent ( language would stay in CApplication) and you could call :
$this->t('my_category', 'hello world');
Posted 26 March 2013 - 05:44 AM
// In your module's init(): Yii::app()->sourceLanguage = 'en';
Or is your question about how to create the message catalogues in this case?
Posted 26 March 2013 - 07:52 AM
... or call some piece of code outside of itself ?
... or maybe in another module that itself (that would redefine the sourceLanguage) ? ...
(and I'm not even talking about reloaded modules )
What about extensions ? I mean, to take a module as example is ok, but my concern is with any third party component included in a webapp. Imagine I have plenty of friends all around the world, each one with a single goal in life : provide the best component (widgets, etc ...) to my great webapp ... and possible to the whole Yii community. Each one should be able to use its own sourceLanguage, and the host webapp should be able to take that into account.
Posted 26 March 2013 - 07:56 AM
* If you create an extension (which could also be a module) that contains text, use 'en_us' as source language if you want to make it easy for others to use your extension
* If you write an application that will use extensions (which could also be a module) that contain text, then use 'en_us' as your sourceLanguage to make your life easy
Posted 26 March 2013 - 08:25 AM
In fact, English is the most convenient language, not just for the native speakers but also for all the rest.
If I ever want to provide some translations of my work, the first one should be "en_us", because it will be the most useful one. And, I will be sure to swap the roles of "ja" and "en_us": I will rewrite my source in English and create a translation in Japanese. It will make it much easier for others to create other translations.
BTW, what "tl;dr" stands for?
Posted 26 March 2013 - 09:39 AM
It usually marks the summary of a really long text/post so that if people don't want to read the long text, they can skip to the summary.
I think it's natural to write in English, not only for the default source language, but also for the code: function names, comments, etc.
I mean: PHP is based on English, as is every other programming language (SQL included).
Posted 26 March 2013 - 09:43 AM
As jacmoe said - but in this case rather "too long, didn't read" - which means that i'm a lazy bone and hate to read lengthy posts. BTW it's my belief that real languages behave much like programming languages in this regard: The experienced programmer (or speaker, writer) will use less code (or words) to express the same information .