schmunk42/yii2-giiant

Combine giiant and translate behavior

Opened this issue · 13 comments

Is it possible to combine giiant with https://github.com/2amigos/yii2-translate-behavior
So the crud creates fields from the *_lang table for all languages.

Could you describe a bit more how you think the UI should look like.
It is definitely possible to write a provider for this.

Lets assume the languages are dutch, french and english

The tables:

news

id
active
date
time_created
time_updated

news_lang

id
news_id
language
title
text
slug

After crud generation, create, I see this:
active (all languages)
date (all language)
title (nl)
title (fr)
title (en)
text (nl)
text (fr)
text (en)
slug (nl)
slug (fr)
slug (en)

And we can expand this with a tabs layout:
ktw4p

De items for all languages (active and date) can be shown in a tab called 'all languages', or maybe better, they are in the tab with the default language, and the other tabs show the translatable items only

I would be interested in this too.
But i prefer the db schema that this extension use:
https://github.com/OmgDef/yii2-multilingual-behavior/blob/master/README.md

Basically the default table still hold the default language and the _lang one only the additional translations for the fields.

I would suggest alternatives to the tabbed interface

  • either having all fields and translations on one single page
  • either having a language selector on the fields that allow translation

I can help for the development but im still new to yii2 so any directions to be shared would be helpful.

Thanks

This would be an excellent idea.

https://github.com/OmgDef/yii2-multilingual-behavior/blob/master/README.md

Specially with the OmgDef multilingual behavior port.
I usually use Gii default CRUD, but you have nice features.

But there's little use to a CRUD Generator that not only doesn't acknowledge the fields into something awesome, like the idea suggested above, and actually throws an Exception, instead of just ignoring (like the normal Gii) the fields generated by the multilingual behaviour.

It throws: yii\base\ErrorException
When it tries to: " $column = $generator->getTableSchema()->columns[$attribute] " it fails because it finds the multilingual behaviour, example:
Undefined index: title_en --> title_en (the translation of a field to English)

This would be a great feature.

Handling the exception or just preventing it at all would make this extension an extremely powerful solution.

Could you provide a schema or migration with the use case?
I'd like to have some test schemas anyway...

Hello schumnk42,

Here is a example schema for the yii2-multilingual-behaviour.
Finding in the Products Model returns ie: title and title_en (If English is in our array)
If you check the yii2-multilungual-behaviour, find() is extended and we have an array with the fields to be translated

productlang_schema

I think it would be much easier to create a CRUD, if the related languages are available via a relation and not as additional fields in the model.

We'll try to provide an example of what's currently possible this week. CC: @Quexer69

@schmunk42
The behaviour comes pretty handy, I'll give you an example:

We have a defaultLanguage ('pt') and otherLanguages ('en', 'fr').

$model = Model::findOne(1) or find()->one();
$model->title; // shows the pt = Portuguese default translation

When we define \Yii::$app->language = 'en';
The same find allows:
$model->title; // becomes the translated en = English translation

However, the 'title' and 'title_en', only appear together when using Model::find()->multilingual():

  • That's why the default Gii CRUD Generator doesn't throw an error, as the fields are not present in the model, I haven't really figured why your CRUD finds them

And multilingual() is pretty useful, to make automatic tabbed languages, like going through an array with languages, and adding in the tabbed section, the fields for title_en and etc,.

Rather then having to implicitly call a relation for it.

Hey guys!

Any luck with this? I've been tinkering around with the code to bypass the issue but it doesn't quite work as it should in some cases.

Have you tried using a special CRUD scope with safeAttributes() to select the fields to render?

Something like this is what I implemented in #114

Hi guys, as my co-worker said in another comment, currently we have holidays in Germany so it will take about 2-3 weeks to review all the great looking PRs etc. please stay patient until then. Thanks.