Yii::t() should fall back to substr(Yii::app()->language, 0, 2)

[fiesh]

When you have your target language set to say fr_fr, Yii::t() should first check if there is a translation in fr_fr, and then, if not, fall back to just 'fr'. For example, setting your language to fr_fr will not even produce Yii's native translations!

Is there any negative side effect of this? I cannot think of one.

[njasm]

Never thought about this, but you might have a valid point here.

[cebe]

Came across this issue too, just yesterday. Not easy to solve in current code.

[qiangxue]

We don't support language fallback mainly for performance concerns.

Language fallback can be done at different places. For example, if your application only supports 'fr', then whenever your get 'fr_fr' from user, you can change it to 'fr', thus avoiding the issue you describe here.

If your application supports both 'fr' and 'fr_fr', but your message translations don't, you can use some external tools to build up your messages so that both languages are supported.

[njasm]

Since Qiang was very clear regarding translation fallback inside yii i didn't conduct further testing ... but I got an initial version that's working with php files translations (no db source translations tested).

if Performance is not a 'BIG' concern to you/your project, take in consideration this new implementation of CMessageSource::translateMessage()

https://gist.github.com/91209e1278e14051f555

if you really want fallback translation you could also use onBeforeAction() to substring language to 2 char in size (if for some reason language are 5 char length and you don't have a way to control that), just don't forget to rename all your translation language folders to two chars in length too (if you using PHP files translations, i've never used db source translations).

Kisses and Hugs.

[fiesh]

I disagree with Qiang's statement that you can just change the language to the short 2 character version. You might still want the formatting of currencies and numbers to depend on the longer locale (en_gb and en_us are vastly different, for example). Also, if there was an option $fallback for the CMessageSource, it wouldn't imply any performance penalty. As for implementing it, one can just alter translateMessage() in CPhpMessageSource, that's what I did, and it works fine. (Oh, njasm also did that, the implementation is very similar to mine, thanks.)

So I remain this would be a good feature ;)

All the best!

[qiangxue]

I'm not saying using 'en' to represent both 'en_gb' and 'en_us' (we know they're different).

What I was suggesting is that the fallback can be done earlier than on-the-fly because the fallback mechanism is not trivial (could go as many as 4 layers, c.f. http://userguide.icu-project.org/locale#TOC-Fallback)

[mdomba]

This is similar to #698

[fiesh]

Qiang, sorry, then I misunderstood what you said. I wasn't aware of the fact there's a standardised fall back routine. I agree that this should be implemented then. But I can't tell how big the performance impact would be, it doesn't seem noticeable for me, but then it might vary.