Yii::t() - reorder parameters

Yii 2.0 General Discussions
1

Hello everybody,

Recently I decided to define some shortcut global functions inspired by qiang’s tutorial.

And I have something like this for Yii::t() shortcut:




function t($message, $category = 'myapp', $params = array(), $source = null, $language = null)

{

    return Yii::t($category, $message, $params, $source, $language);

}

And call it in code is so clean and beautiful:




echo t('Some message...');

But there is one issue if you use yiic MessageCommand to extract messages for translation.

Obviously you need to set translator varible in config file to be your custom translating function (in my case it is t) and that’s all. But you won’t get extracted messages.

That’s because regex for matching your translator function expects $category to be first argument:




/\b'.$translator.'\s*\(\s*(\'.*?(?<!\\\\)\'|".*?(?<!\\\\)")\s*,\s*(\'.*?(?<!\\\\)\'|".*?(?<!\\\\)")\s*[,\)]/s

My suggestion for Yii 2.0 is to reorder parameters in Yii::t() so $message become first, and $category second. And of course to edit regex in MessageCommand.

Cheers

2

But params must also be bound to the message - so you also would need to set params prior to category, because they may change more frequently than category. So your proposal should be:




Yii::t($message, $params = array(), $category = 'main', $source = null, $language = null)

But I am not sure if this is good idea, sorry:-)

What if somebody does not like category="main"?

3

Yes, think you’re right about params. If someone doesn’t like default category he always have chance to change it, or can make wrapper as explained in my previous post :)

4

Moving the params is a bad idea. I have 3 multilingual projects with 15-20 translation categories containing a lot of text (one project has ~250KB of data PER language). I estimate my usage of the params at about 5-7%, but the usage of the category param is 100% - I specify it for EACH translation message we have.

So I would support switching the $message and $category params, but do not touch other params. This will make the development of small-scale applications witch do not need many categories for translations. But moving the params will be a major pain for everyone.

5

I don’t see the logic behind this, its very easy and quick to overload this method with your own and put it any order you want. Params shouldn’t be changed in methods as it’ll cause backwards compatibility issues breaking existing applications and causing inconsistencies in documentation.

6

I’ve read that backward compatibility isn’t a priority for the new major version. The important thing is to offer an upgrade path (i.e. “please note that you have to change the params order for this and that”).

7

Yes, that’s true.