Is 'cfgFile' used by 'yiic message' command only?
Are there any reasons to use t() in framework's code instead of raw strings for messages intended to be observed by a developer only? It would be easier to understand which framework's messages must be really translated at case with raw strings.
Probably it would be handy to prefill values (targets) with keys' strings - at least placeholders woud be ready, reducing errors possibilities 
"yiic message" needs a config file to know many parameters. See framework/messages/config.php for an example that is used to extract framework messages.
t() is used to do message translation. All framework messages are subject to being translated into multiple languages.
I don't quite understand. Could you explain a bit more?
I think what anli means is that the language files should look like this (before you modify them):
return array( 'Translate this please' => 'Translate this please', 'Roses are red' => 'Roses are red', 'Violets are blue' => 'Violets are blue' );
So that a call to Yii::t won't return an empty string, which it actually won't, because if the value (in the language file) is empty, the key will be returned, correct?
Thanks for explanation. Seems reasonable to me. Will make a change.
Ok, now you lost me. I do not see the need for what anli is proposing. If I do a
Yii::t(‘someCategory’, ‘This has yet to be translated’);it returns “This has yet to be translated”. What I was trying to get at was that anli had misunderstood how Yii::t works. Filling up values with their respective key seems kind of unneccessary when Yii::t already has this behaviour. I’m curious about what you thought I meant, since I don’t really think I was proposing to make a change in how i18n works.
If i understand correctly, what anli proposed is that the prefilling of the translation values will simplify the translation because the placeholders are copied and do not need to be re-typed during translation.
Ah, of course. That does make sense. Sorry for making things more confusing.
Quote
Yes, I see. The question is: is "yiic message" the only peace of code which use this cfg?
Quote
But most of them are not subject of rendering to end users (site's clients), They just tell about developer's error. It would be handy to separate such messages into another category or just use raw strings. This way we reduce significantly an anount of messages needed to be really translated.
Quote
This suggestion is right: 'Roses are {holder}' => 'Roses are {holder}'.
Yes.
Well, not all developers can read English. That's why we do the translation for those core messages. And they ARE treated differently from application messages.
Quote
Aha, I see, it is just design decision. Thanks! At any case it is possible to select only needed directories for translation (say, validators and auth-related) using multiple config files: I have tried - it works To eliminate a needing to use multiple config files (and, as a result, merging process) it may be handy to slightly extend 'sourcePath' semantics, alowing an array of paths also.
Unless your code spread is widely spread (not likely), you can always use a single "sourcePath" and use "exclude" to exclude those unwanted directories from message extraction.
Quote
Say. to generate translations for 'validators' and 'web/auth' only, I need to exclude ~20 other dirs. And I don't understand how to exclude web/*.php files but keep 'web/auth' dir. Paths array would be more handy, to my taste
At any case all this isn't any kind of showstopper, and, probably, you have in hands more important and interesting things to do. Thanks!
Qiang,
let me know if you need a helping hand for german translations of those messages.
That'll be great! I just added German message folder to the 1.0 branch. Please let me know if you need other info. Thanks!
I'll give it a try. Do you have any preferences on application specific terms like "application", "alias", "path" that might reflect class names or configuration parameter names? I would say, that these words should not be translated…
I think either is fine. You decide. 
A first version is ready. Might need some corrections here and there, but it's a start.
See attachment.
And already a corrected version 
Some translations weren't clear to me since i didn't get the context. Maybe you can explain a little:
No columns are being updated to table "{table}".
No counter columns are being updated for table "{table}".
That was really quick!
This message occurs in CDbCommandBuilder::createUpdateCommand() when no columns are being updated (because the user specified data do not contain any valid column).
This is similar to 1. It occurs in createUpdateCounterCommand().
O.k. i've done some small changes. I guess, the translation for "counter column" sounds a little awkward, but leaving it as "counter column" would be the same.
I'd say, it should be o.k. for now.