Validator message format

[cebe]

Fixes #991.
ICU message format is now available for gridview summary and all validator messages.
It is not available for client validation as some params are added in JS.

[samdark]

Have you meant ICU instead of ITU?

[cebe]

Have you meant ICU instead of ITU?

Yeah, of course :)

[samdark]

It seeems there's a lot of duplication between format and translate. I guess format can be used inside translate.

[cebe]

It is quite duplicated but the error messages are not that nice anymore when we just use format in translate.

[coveralls]

Coverage remained the same when pulling 3631890 on cebe:validator-message-format into 752037d on yiisoft:master.

[qiangxue]

Let me merge it first. Good job!

[qiangxue]

I refactored the code as @samdark suggested. The large chunk of duplicated code is not good. For this reason, we can tolerate the less perfect error message.

I also think perhaps we should reorganize/redesign the current MessageFormatter and FallbackMessageFormatter:

• Instead of extending from the intl MessageFormatter, we create a new MessageFormatter class which mainly provides the method format($message, $params, $language)
• The format() method will use intl MessageFormatter to do the actual work if intl extension is installed. Otherwise, it will call its fallback implementation.
• I1n8 class can implement getMessageFormatter() and drop format().

What do you think?

[cebe]

Why? Imo having I18N::translate() and I18N::format() looks like a good interface to me. You hardly ever need the message formatter instance. Doing $i18n->getMessageFormatter($language, $pattern)->format($args); does not look that good to me.

[samdark]

@qiangxue what's the con to have MessageFormatter extended as it is now?

[qiangxue]

Ok, we can keep I18N::format().

The current MessageFormatter is fine if we plan to let it be used alone (but then you won't be able to use FallbackMessageFormatter). But since we modified it with replaceNamedArguments(), I suspect anyone will use it alone.

The design of FallbackMessageFormatter is very clever. However, it is a bit twisted, and it may also cause problem to phar support like this: #261.

[cebe]

You can use the MessageFormatter or FallbackMessageformatter alone if you want. There is just no sense in using the fallback one as Messageformatter already checks for intl extension installed.

whats the problem with phar?

[qiangxue]

This is what I proposed: https://gist.github.com/qiangxue/6641b25650d8699952ba

[samdark]

@qiangxue why extends Component? It's not using anything from component, isn't it?

[cebe]

Extending Component is fine as it is a yii class. idea looks okay to me. fallback handling is not correct though.

[samdark]

@cebe but it's not used anywhere: there are no events, behaviors, getters or setters. Also it's not used as a component.

[qiangxue]

This is just a 5-minute work to explain the idea. The class can extend from Object instead of Component.

[cebe]

I think provided idea is better than current solution. Will handle it together with #1062.