Add i18n support for ActiveRecord

[Zonitsuka]

At the moment this can done via behaviors like the following:
http://www.yiiframework.com/extension/multilingual-behavior/

I18n handling is needed by most modern websites, so it would be great if it becomes part of the framework functionality.
The i18n table structure is already in use for Yii::t()

[realtebo]

+1, in particular way, we need a way to handle with flexibility to date and time formats, which are often bad-definited in yii 1.*

[jamguoxiaoqi]

+1 i18n for ActiveRecord

[schmunk42]

For reference, other implementations:

• https://github.com/mikehaertl/translatable
• https://github.com/schmunk42/p3extensions/blob/master/behaviors/P3TranslationBehavior.php

[philippfrenzel]

+1

[motin]

Even more implementations:

• http://www.yiiframework.com/extension/i18n-columns/ (https://github.com/neam/yii-i18n-columns)
• https://github.com/firstrow/STranslateableBehavior
• https://github.com/deeptowncitizen/MultilingualCrud
• http://www.yiiframework.com/extension/yii-language-behavior/
• https://github.com/belerophon/yii-multilingual-behavior

[creocoder]

Vote against this feature in core. Multilingual behavior can be done through many ways.

[klimov-paul]

“i18n” is not correct name for the feature, which is described here.
I prefer to call such feature “variation”. Particular entity may have attributes, which values vary depending on the some option choice.
The most common example is an attributes translation, when item title and description display value depends on the chosen language. However there are other usecases, where this could be useful.
For example: let’s assume we have a shop, which supports several currencies for the payment. So each item in the stock actually has several prices: each per each system currency. While browsing item catalog user see the prices in the currency he have chosen.

[klimov-paul]

[samdark]

Looks like application design problem, not a framework one but if you have a good idea solving it once for all possible cases, it would be interesting.

[motin]

Just released a new implementation: http://www.yiiframework.com/extension/yii-i18n-attribute-messages/

[nineinchnick]

@klimov-paul using your example there are still too many solutions to try to solve this in the framework. Consider a case when some records doesn't have one variant. Sometimes they need to be filtered out instead of using a default value.
Also, the solutions limit/depend on the database schema too much.

[motin]

@nineinchnick I do not propose that any solution be included in the core, but all solutions to not limit/depend on the database schema (as long as we talk i18n only here, that is, not a general way to solve variation..). The i18n-attribute-messages solution simply uses the Yii::t() method and it thus not dependent on any particular database schema. It does however support saving translations if you use CDbMessageSource. Instead of returning a default value, one can use the onMissingTranslation handler to use null.

[VinceG]

should probably be an extension not a core feature. i haven't seen a PHP framework that has this as part of the core.

[rubenheymans]

is an extension like this available for yii2?

[cebe]

not yet, as far as I know.

[OmgDef]

I ported http://www.yiiframework.com/extension/multilingual-behavior/ to yii2. https://github.com/OmgDef/yii2-multilingual-behavior

[hdogan]

@VinceG CakePHP has Translate behavior.
http://book.cakephp.org/3.0/en/core-libraries/behaviors/translate.html

[klimov-paul]

https://github.com/yii2tech/ar-variation

[dynasource]

I dont think it is a bad idea to create a connection between AR and the translation components. I have this implemented in my own projects and it has proven to be useful.

Perhabs, even a connection to Object would be possible. Something like this:

• $object->translate()

This is so generic that it can be adopted in the core IMHO. Does anyone have similar implementations or ideas about this kind of architecture?

[samdark]

• Simple maintenance
• Easy to add translations
• Proper foreign keys
• Only one join
• Need one table per translated content type

[samdark]

Language should be canonicalized w/ Locale::canonicalize($language);.

[dynasource]

hmmm...I think we are talking about 2 things here:

• translation of attributes (or other class properties)
• translation of user added content

[samdark]

Nope. These two are the same. User added content is stored into attributes.

[dynasource]

User added content is stored into attributes.

can you elaborate? How should I see this....

[samdark]

I mean when you're saving any content it's saved into model attributes. I proposed a way to store these in a separate table depending on a language. The solution is good but you can't really automate it since it requires careful DB design.

[dynasource]

I tend to see a DB implementation out of the Yii's scope. We could start small with a architecture in which it is easy for a user to translate its AR attributes.

[samdark]

What's AR attributes? Do you mean labels or what?

[dynasource]

yup

[samdark]

Labels are already covered by Gii. There's a checkbox for wrapping em in Yii::t(). This issue is about data, not static stuff.

[dynasource]

alright, in that case its in the data scope and out of Yii's core scope.