Yii Framework Forum: Backward Compatibility Questions - Yii Framework Forum

Jump to content

  • (2 Pages)
  • +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Backward Compatibility Questions

#21 User is offline   Ben 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 267
  • Joined: 15-March 09

Posted 11 May 2013 - 07:18 PM

I was just thinking about another possibility:

Rename that method in YiiBase to "translate", only support the whole load of parameters and let people define their own shorthand helper method in Yii. Looking into the code, I see there already is a method named "translate" and "t" actually is a shorthand helper method. :D

Now, what I also saw is, "translate" uses the same signature as "t" does. May I suggest to remove the string mangling at least from the "translate" method (I18N component)?

I'm not so picky about the shorthand methods in YiiBase. No problem with taking a pragmatic approach there. If someone doesn't like it, he can quickly write a wrapper of his own, or use the l18n component directly.
Don't like ads in my sig...
1

#22 User is offline   qiang 

  • Yii Project Lead
  • Yii
  • Group: Yii Dev Team
  • Posts: 5,876
  • Joined: 04-October 08
  • Location:DC, USA

Posted 11 May 2013 - 08:22 PM

I'm open to suggestions. Note that we should also consider the message extraction tool. The new syntax shouldn't cause too much difficulty for creating such a tool.
0

#23 User is offline   Ben 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 267
  • Joined: 15-March 09

Posted 11 May 2013 - 08:53 PM

Yeah, was also thinking about that. Will it be based on scanning the source using regular expressions? The only other thing I can think of is collecting strings at runtime. Runtime extraction might be more accurate, because it would cover variables being passed to the translation methods. The downside is, that you first have to run the code and to reach every bit of it...
Don't like ads in my sig...
0

#24 User is offline   yJeroen 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 94
  • Joined: 06-September 11
  • Location:The Netherlands

Posted 12 May 2013 - 03:04 AM

Idea.. Why not use your namespace name as "category" ?
0

#25 User is offline   Müller 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 24
  • Joined: 23-June 12
  • Location:Netherlands

Posted 12 May 2013 - 05:28 AM

What I did in Yii 1.1:

Created a class named T with some methods msg, atr, act. In Yii2 would look something like:

Class:

namespace yii;

class T {
	public static function msg($message, $context = null, $params = array(), $language = null) {
		return self::translate($message, $context, $params, $language);
	}

	public static function translate($message, $context = null, $params = array(), $language = null) {
		if (Yii::$app !== null) {
			return Yii::$app->getI18N()->translate($message, $context, $params, $language);
		} else {
			return is_array($params) ? strtr($message, $params) : $message;
		}
	}
}


Usage:

namespace myApplication;

use yii\T;

T::msg('name'); // default context [category]

T::msg('name', Person::className()); // name in the Person context

T::msg('name', __NAMESPACE__); // name in myApplication context


As you can see I'm also proposing to rename the "category" parameter to "context" as I think it fits better in the context of translating.

I think its better to introduce another class where the developers can extend from it and customize it as they judge it better. The default method (T::msg) is as short as (Yii::t) and if all translations method are in the same class, it's easier to create the regex for the message extraction tool.
0

#26 User is offline   Jaggi 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 90
  • Joined: 05-September 11

Posted 12 May 2013 - 06:10 AM

View Postjacmoe, on 10 May 2013 - 02:06 PM, said:

Printing instead of returning is bad - that is not good functional programming style: the functions have side-effects. Or, put differently: they do things behind your back.
I do like the change.
If we want it printed, we print the data that we get from the function.
It also makes it easier to chain function calls, concatenate, delay output or send it to another function.
Good programming practice IMO.


I can agree with that.

View Postqiang, on 10 May 2013 - 03:53 PM, said:

The main reason for the Yii::t() change is because I want it easier to use if your category is the default one (which is the case mostly). For example, you can use Yii::t('translate me'). Without this, you have to type Yii::t('app', 'translate me').


By doing this you've only made it more simpler for a very small percentage of users and not actually benefited the end user. This will mostly benefit the core framework and extensions and even in extensions most people have custom categories.

I do and don't agree with the array method - it solves the problem but isn't great programming methodology as the parameters aren't obvious to the user and their IDE.

I would purpose something like:
public static function t($category, $message = null, $params = array(), $language = null)
{
	if ( is_null( $message ) )
	{
		$message = $category;
		$category = 'app';
	}
}

Yii::t('my message');
Yii::t('category', 'my message');


Yes its not the prettiest code you'll ever see but is just an example and it will require some further code to make sure message is set if params are but solves the problem and practically no overhead.

Also looking at the current method it adds overhead of the strpos and preg_match which it does twice. Once in the t() function and again in the translate() function.

Of course we could just leave it how it is as another option.
See my development site @ www.CodeTheInter.net (BETA)

Posted Image Posted Image

Quote

If you make it idiot proof, they'll build a better idiot
0

#27 User is offline   François Gannaz 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 87
  • Joined: 24-November 09

Posted 12 May 2013 - 09:18 AM

For your information, in other frameworks:

  • ZF1 and ZF2: $this->translate($string, $category = '')
  • Symfony2: $translator->trans($string, interpolationArgs = array(), $category = '')
  • Drupal7: t($string, $interpolationArgs = array(), $options = array())
  • Moodle: get_string($string, $category='', $interpolationArgs...)


Moodle is not a generic framework, but a popular Learning Management System coded in PHP.

So, with these PHP frameworks the l10n string is the first parameter, and the translation category is an optional second or third parameter.
0

#28 User is offline   Tsunami 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 150
  • Joined: 16-February 12

Posted 12 May 2013 - 09:34 AM

View PostJaggi, on 12 May 2013 - 06:10 AM, said:

I do and don't agree with the array method - it solves the problem but isn't great programming methodology as the parameters aren't obvious to the user and their IDE.

PHP callbacks use the same format though, a string for a plain function and an array for a class method. I think with proper documentation people will pick it up quickly.


View PostFrançois Gannaz, on 12 May 2013 - 09:18 AM, said:

So, with these PHP frameworks the l10n string is the first parameter, and the translation category is an optional second or third parameter.

The unfortunate thing about all of those solutions is that, as qiang said, the message command should still be able to easily parse these messages. Right now it uses a single regular expression, so the only format that's easy to parse is

Yii::t($message, $category = '', $params = array())

which means that if there are parameters but no category, you always have to pass ''. I think all of the solutions given in the previous posts, including the array method would probably make it a lot more complicated for parsing.

I have to say at first I also didn't like the pipe format, but on the other hand, it's already used for plural forms in Yii 1.


Edit: what would be nice is a property on the i18n component, to configure the default category, instead of it always defaulting to 'app'. For some (public) apps I prefer to use the name of the app instead. But maybe that's a discussion for a different topic.
0

#29 User is offline   Ben 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 267
  • Joined: 15-March 09

Posted 12 May 2013 - 11:20 AM

Question is if we need to provide a custom message command. We could as well use some existing solution like xgettext. It doesn't support javascript out of the box though. And even if there will be a custom message command, I don't really mind if it is bit more complicated or if it uses a bunch of regular expressions instead of only a single one. As long as it does its job, I'm fine with it. ;)
Don't like ads in my sig...
0

#30 User is offline   Ben 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 267
  • Joined: 15-March 09

Posted 13 May 2013 - 07:53 AM

@Müller & @François Gannaz:
I think it's more common to use parameterized messages than to use different message contexts or the necessity to specify a target language. That's why imo the method should allow to skip those two rarely used parameters, even when $params are present.

I prepared a variadic version of the method, providing similar functionality to @Jaggi's suggestion. You can hava a look at it on my variadic-yii-t branch. I'm not really happy with its parameter naming though...
Don't like ads in my sig...
0

#31 User is offline   Müller 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 24
  • Joined: 23-June 12
  • Location:Netherlands

Posted 13 May 2013 - 08:22 AM

View PostBen, on 13 May 2013 - 07:53 AM, said:

@Müller & @François Gannaz:
I think it's more common to use parameterized messages than to use different message contexts or the necessity to specify a target language. That's why imo the method should allow to skip those two rarely used parameters, even when $params are present.

I prepared a variadic version of the method, providing similar functionality to @Jaggi's suggestion. You can hava a look at it on my variadic-yii-t branch. I'm not really happy with its parameter naming though...


I think category/context is more common than parameters. Think about modules/extensions, they are required to define the category/context.
0

Share this topic:


  • (2 Pages)
  • +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users