Add Language property to ECK

Ok, so the main reason to have those "default" db fields as options, to be quickly added when creating an Entity Type, is that they come with some functionality already: created and changed save a timestamp appropriately when an entity is created or updated, uid saves the id of the user that created the entity, etc. ECK itself currently breaks that rule, as UUID, and state do absolutely nothing, yet. But the point is that in the next few release (which should be coming very soon), they will be doing something. If the only purpose of a db field is to store data (no special logic, or functionality is associated with it), then it should be defined as a custom field. I have not work with multilanguage systems before, so, is there any special functionality that would be associated with this language field?

I'm reopening this issue, since I believe language field for entities makes sense.

I use ECK to build parts of contents that do not need to be nodes (no need for a page, url, title, I don't want a user with "access published content" to see it elsewhere than where I've decided...).

But some of these parts still need to have a language.

Think about an editorial, that should be only displayed on the homepage.
In a multilingual site, this editorial should be created for each language.

Then in Views, you would want to filter editorials by its language, so that it shows only current user's language.
That's basically how you would do it for nodes.

In my entity bundle, I can set a field called "language", but there won't be any available functionnality associated to it.

What do you think of that?

I've seen this post, but I don't understand how it works, how I should do, where do I need to look : D7 has now has full Entity language support

So according to the new "Behavior" paradigm adding a language field is done via implementing language specific behavior, right?

Providing a patch. Please test it.

Patch works as advertised. I was able to set the property and see it saved and displayed.

Here are a couple more text options for the description field, in addition to, The language the entity is in.
* The language of the entity.
* The entity language.
* The entity's language.
* The language specific to this entity.
* The defined language of this entity.

Patch #7 works for me.

However (I know it's a quick integration), when creating a view and making a filter based on language, I only get "Language neutral", and the languages I've activated for my site (EN, FR ...).

When working with nodes we have two more options in the language filter which are "Current user's language" and "Default site language".

I don't know if ECK should provide a language filter handler for views.
Please see "modules/translation/views_handler_filter_node_language.inc" or "modules/locale/views_handler_filter_locale_language.inc" in views module.

It would be great if ECK could have full multilingual support!

Thanks for the good work!

Sorry, I didn't want to change the settings, this was not intended. (I can't re-assign the issue).

@dolu

I believe you are right about where the code should go. Recently I added similar support to Commerce Products (see: #1723826: Add Language views handlers (field, filter, argument and sort) to Commerce Product) so I think we can use the same approach here.
They only difference/difficulty I see - is that language property list and names should be retrieved via either behavior = language or type = language condition and then iterated through, adding necessary locale-hooks.

I've tried making a basic language filter, but I've gone through some issues :

- When adding the language to eck_views_data_alter() :

    $data["eck_{$entity_type->name}"]['language'] = array(
      'filter' => array(
        'title' => t('Language'),
        'help' => t('The language the %entity_label content is in.', array('%entity_label' => $entity_type->label)),
        'handler' => 'eck_views_handler_filter_entity_language',
      ),

I think there may be a name conflict with the already created "language" property.

- In eck_views_data_alter(), I think we should test against the entity type if language has been activated for it. But when looping through entity types, $entity_type only contains $entity_type->is_new = FALSE;

- And finally when adding the filter in the view, I have a broken/missing handler.

* Added views handlers for language fields

#13 patch works as expected for views filter, sort and argument.

There is still a little glitch somewhere, because the language field doesn't return anything (empty string).
This fires the following error (php notice) :
Notice: Undefined variable: options in views_handler_field_locale_language->render() (line 27 of D:\my-site\sites\all\modules\views\modules\locale\views_handler_field_locale_language.inc).

@dolu

I can't reproduce this bug. Would you provide more details on this?

After installing the module (patched) :

• Create a new entity type with a bundle
• Add language property
• Create one or more entities

Then viewing the entity, language is not displayed.

When creating a view and adding the language in the fields list (i.e. in a table display), the column language is displayed but it contains no value and generates PHP notices.

I think there is a difference between patched ECK and standard nodes (with locale module enabled) :
When you add the multilingual support to a node type, the language field becomes available as a standard field (e.g. display settings) in admin/structure/types/manage/page/display.

This doesn't happen with pacthed ECK in admin/structure/entity-type/test/test/display.

Maybe this a clue to resolve this issue (Should the field be provided through Field API?).

@dolu

Are you using git version of ECK?
I've just made clean install of D7 with stable Views, Entity API, Ctools and ECK from git + the patch. I see no notices and language displayed (neutral). Locale is disabled.

I'm using latest dev version with #13 patch.

I just tried with a fresh Drupal installation, everything looks correct.

So how you prefer to treat the Notice? Should we dig further to reveal the reasons of it?

Leave it for now, it was a database where I made all my tests of modules/configurations etc...

I've tried now in a fresh database (deleted the old one, so I cannot reproduce for now), with Locale and I18n enabled, all is working fine at my side.

We still need the opinion of the maintainer, and maybe more reviews?

Let's kick this off.
Setting to NW since we haven't come to understanding where this should live - in ECK or somewhere else.
My vision is:
* Leave this in ECK
* Next task: Add locale support to make bundles locale-sensitive. Here or in a separate module?

Ideas?

There is a minor deviation from the Drupal's way in the proposed patch.

In Drupal 7, if you don't have Locale module enabled, this is how Node entity works:

1. Content type form: you can't select if your Node bundles be locale-specific (Mutilingual support) or not.
2. Node edit form: you don't have Language drop-down widget.
3. DB: node table has Language field in the DB which defaults to LANGUAGE_NONE for any node (language neutral).

then after you enable Locale module:

1. Content type form: now you have "Multilingual support" widget with values No (default) and Yes. If Yes, then
2. Node edit form: you have Language drop-down widget now.
3. DB: value is taken from Node edit form.

now after you enabling Content translation module:

1. Content type form: Now you have one more option for "Multilingual support": Yes, with translation, and if set to Yes:
2. Node view page: you get Translate tab which enables old-style node-clonning translate technique.

Now back to ECK and added Language property. This is how it works now have you Locale module enabled or not:

1. Entity type form: You can add Language property (to be honest - you can add any number of Language properties with any names which barely makes any sense, but this is how other ECK provided properties work: created, updated - who will ever need to create more then one of those, huh? :-) ).
2. Entity edit form: You have Language drop-down widget.
3. DB: The value goes to corresponding DB field.

The possible deviation I told before is in appearance of Language widget on entity edit form with Locale module disabled. A drupalish canonical behavior would be to hide this field until Locale is enabled. But... what if we use Language field for completely different things?

Waiting for your comments, comrades :)

A different approach would be to not exposing Language property in the Entity properties UI. This is how it may work alternativaly:

• First you dl & install a module called say eck_locale.
• Entity type form: there is now a "Multilingual support" checkbox, which
  • when checked, then upon the form submission, a new Language property is added to the Entity type's config and to columns of the entity's data table (if it was not created before).
  • when unchecked, then upon the form submission, a Language property is not added or removed from the Entity type's config and from columns of the entity's data table (if it was created before).
• Bundle edit form: if Entity has "Multilingual support" enabled, then we see "Multilingual support" widget which looks and acts like the one from Content type form
• Entity form: if Entity and Bundle has "Multilingual support" enabled, there is now Language drop-down.

Thoughts?

Yes, this might be close to what people expect when playing with multilingual support.

However, I have few remarks/questions :

• Shouldn't the multilingual support be activated only on the Bundle edit form, as for nodes (content)?
• Should the locale support be directly integrated in the main ECK module? When enabling core Locale support, multilingual support is directly available for several entity types (such as nodes and users). People might expect to have the same behaviour.

Hope this helps to get in the right direction.

@#26

• Shouldn't the multilingual support be activated only on the Bundle edit form, as for nodes (content)?

At first sight - it should. But Nodes (for example) already have Language field in DB, while arbitrary ECK entity - hasn't, until we add it explicitly. In other words, enabling multilingual support on the Node's Bundle edit form simply makes Language widget to appear on the Node form, while enabling multilingual support on the ECK Enity's Bundle edit form should also implicitly create a Language field on that entity's table then.

Even if this 'transparent' creation of a Language field may look like a good idea, this could have consequences:

• Is this evident and appropriate for a user, that enabling Multilingual option for one bundle will create Language field on the entity and will make all other bundles' entities to start getting 'LANGUAGE_NONE' (und) at the DB level?
• What is expected behavior when once enabled multilingual option then disabled for all bundles of an entity type?
  • If we had a Language field which we created manually, then its pretty obvious that it should stay there until deleted. Everything looks clear to my mind.
  • But in case of 'transparent' operations and implicit field autocreation, I doubt that a user wants the field gets deleted (and all language settings for created entities will be lost) and for this reason we should stay the field untouched. Then how we would delete the Language field after all? It is a construction kirt, it should provide control over such kind of things :)

And what about having the language column in DB always created, even with multilingual support disabled?

Then when enabling core "Locale" module, language options for entity types and/or bundles would be available.

That would be pretty the same behaviour as nodes, I believe.
But then again, should ECK adopt this very behaviour, or have one on its own?

It may be worth having thoughts from multilingual experts on this issue.

And what about having the language column in DB always created, even with multilingual support disabled?

The reason again - it is a construction kit, which shouldn't require any property to be created - even title. If we decide to make an entity multilingual at some point, we can do this by either adding Language property in the entity properties UI or by enabling a multilingual option on the Entity Type form.

I think the most straightforward and flexible approach should include both:

1. Add a language field on the Entity type properties edit form (this works already).
2. Make an entity multilingual on the Entity type edit form (this step is still required since you have to specify somewhere which language field will hold entity's locale information as there could be any number of language fields).
3. Make a specific bundle multilingual on the Bundle edit form.

UPDATE
Actually, 2nd step could be skipped by adding one more behavior like "Locale language", in addition to just "Language". But we should check if such a field is unique then.

@OnkelTem I noticed that you set up the issue as needs work, only because of the uncertainty of whether this functionality should be in ECK core or not. I would say let's keep it in ECK core. Also I have 0 experience with multilingual stuff, so I will let it up to you and some of the other participants in this issue to decide when this pathch is ready to be commited. I will still give a technical review when the patch is ready, but in terms of the functionality and testing, that will be up to the participants in this issue. I haven't have time to read through the whole conversation happening here, but it definitely is in my todo list, just to see if I can give any input.

Good news that you're willing to include multilingual support in ECK.

Although I'm not a expert, I mostly do multilingual websites, so I can provide tests feedback on this issue.

I've already tried #13 patch, which seems to do the job, but haven't tested it extensively.
Maybe if it is commited to dev version, more people will be able to see if there is still work to do, when using it in more complex cases.

@fmizzell, dolu

Thank you for the feedback.

To make things clear, "needs work" now means adding full Locale support.

Ok this is my plan:

1. Add Language datatype and Language behavior (done with the patch)
2. Add new behavior called "Language Locale" (actual locale of an entity)
3. Add "Multilingual enabled" option to ECK bundle edit form of the bundles which entities have field with this behavior and expose locale language field on multilingual enabled entity edit form.

Things to discuss:

- the approach which uses behavior at all
- the name of the behavior

For behavior "Locale language", I think it should not be provided if Locale module is disabled.
If Locale module is disabled, you don't have any language to show but the default language.

As you say in #24, to have a more powerful multilingual behavior, there should be a "Translation" mechanism, which - for those who are not used to multilinugal - allow to say : this entity (in english) is the translation of that entity (in french).

Then the language switcher knows the path of the content to show when switching langauge. And a third party module could show the percentage of translated and untranslated entities (just as it exists for node contents).

To do that, there should be a "teid" (or something else) column in database and created at the same time as the language column to group the entities. This is called a translation set.
At least, this is how it works for nodes (column "tnid" in node table).

EDIT : Wait a minute. The translation set could be provided through 18n_translation module : hook_i18n_translation_set_info().
It works for all kinds of entity types and bundles. So maybe this should be in separate module (submodule) with dependancy to i18n_translation.

@dolu

I personally encourage the Entity Translation's approach rather then default one (which breeds new entities). So I would bestow more prio to providing ET support :) Are you familiar with ET?

Are you talking about this module http://drupal.org/project/entity_translation ?

I haven't tried it yet, but you're right, it might be the best approach.

Entity Translation is maintained by Drupal core i18n team, so I guess they already brainstormed to get to the best way to implement multilingual support for entities.

Do we need Locale independent language property?

Please, run update.php after applying this patch.

Changes:

Behaviors API

• Added two new hooks to behaviors:
  • bundle_form - to allow behaviors to modify bundle edit form.
  • views_data_alter - to allow behaviors to alter views handlers data.
• Added new property to behaviors: unique - which defines whether two properties of a behavior can be created.

Behavior: Language

• Added support for Locale module.
• Added support for Views.

Properties form

• Added new hook eck__properties__form_validate() - which checks uniqueness of properties with behaviors with 'unique' = TRUE and fires error.

Bundle class/schema

• Added 'config' field to Bundle schema. It keeps serialized config of a bundle.

Bundle edit form^new

• Added new form eck__bundle__edit_form for editing bundles.
• Added submit hook for this form where bundle config is saved.

Menu system ^new

• Added new menu hook <path_to_a_bundle>/edit which opens bundle edit form (It conflicts with ECK Extras!)*

* - ECK Extras implements same hook plus a form for editing bundles. Now when this is in ECK core, ECK Extras should use existing form (and alter it).

What is the upgrade path for using your patch?

I use ECK 7.x-2.0-beta1+20-dev version.
Should I :

• Apply #13 before patch #37?
• Use another version?

I don't know why, but when I apply the patches, I get a "partially applied" message.

Thanks!

This patch is against ECK head, i.e. you don't need to apply another patch.

UPDATE. Sorry, I was wrong. Cleaning up now...

Try this one.

What do you mean by HEAD version?

I tried #40 with 7.x-2.0-beta1 and 7.x-2.x-dev and I still get "partially applied" when applying the patch through Netbeans.

It seems the only error is in eck.install

EDIT : what are you using to apply the patch? CLI git? Sorry, I'm not used to that kind of things.

I've just downloaded -dev from project page.
Then downloaded patch from #40.
They successfully applied it using: patch -p1 < patchfile

I've read documentation here : http://drupal.org/node/60179
Applying patches through Netbeans should work (however, in this case, it doesn't).

Could you upload the patched module, as I don't have time now to install utilities such as GnuWin32 or Unxutils ?

Thanks!

Of course, here it is.

Thanks for that.

I'm not sure about what behaviors really are, it's a bit unclear.
It may be worth adding some explanations and add a "None" option to behavior select box, as it is optional.

However, I've tested multilingual support, everything seems fine to me! :)

I guess we can set it to RTBC...

@fmizzell

Let's do it finally! :)

* minor cleaning up (@dolu, I think I found the reason why the patch was not cleanly applied at your side)
* a bug with setting default language when creating a new entity fixed

* re-rolling, added missing behavior file :)

This patch applies clean against the 2.x-dev branch and does what OnkelTem in #37 stated. Values for translatable fields are saved in the language of the entity. So it seems to work. Multilingual is really a beast ;). Thanks OnkelTem for the work.

The next step should be the integration with entity translation module.

@OnkelTem crap, I commited the patch that was causing the properties not to save, and now this patch will not apply cleanly, would you mind rerolling it. thx.

rerolled

@olafkarsten

Thanks, Olaf, but this one looks pretty strange. It has only difference in that it has t('Add Property') instead of "Add Property" (see the diff).

Let me do re-rerolloing again.

Rerolled against latest div (with fixed non-saving properties in non-English locales)

I wonder why in #52 patch was not cleanly applied.
Also #53 really fixes a new problem - missing t('Add Property') in new function, not in original (like I though).
#55 lacks this.
Now everything should be ok.

hmm, no clue why that's going wrong in #53 :/

applied cleanly against latest dev.

+++ b/eck.properties.inc
@@ -324,6 +335,23 @@ function eck_deactivate_on_save($element, &$state){
+function eck__properties__form_validate($form, &$state){
+  if($state['values']['op'] == t('Add Property'){

missing closing ')' in if statement after t('Add Property')

Shame on me! :)
Thanks!

and finally :D - it works

@OnkelTem Did you manage to translate your ECK Entities with Entity Translation?

@olafkarsten

Not yet. I want to upgrade ECK to support Title module first (to get lables translated), then dig into Entity Translation.

I have issued an follow up #1798646: Make ECK entities translatable (entity translation integration)..

@OnkelTem: I have just updated to the latest dev and was trying to test out the new language stuff. Where does the language widget come into play? From the code in the patch it looks like it should be on the edit page of the bundle which was added. I however don't see it showing up there. I was testing the update process from an older version of ECK before the patch was committed. Have you tested this scenario yet to make sure it works properly?

@acrazyanimal: From the code in the patch it looks like it should be on the edit page of the bundle which was added. I however don't see it showing up there.

It only appears after you add Language property to an entity.

Okay, that is what I did. I added the language property to an entity, cleared caches just in case I needed to and nothing other then the save button shows up on the bundle edit page. ???

@acrazyanimal

Ok, i need to test it myself. Let's clarify the last thing: have you Locale module enabled?

In my case upgrading the module just works.

Note: It's not just adding the property to the entity type. You have to enable MULTILINGUAL SUPPORT on each of the bundles as well.

Thanks to all for the good work!

@fmizzell : when are you planning to release a new version including this feature?

@dolu

Though I'm not fmizzell, let me put in my 2 cents.
I don't think multilanguage feature is ready [for release] until ET integration works (but this is not release blocker of course).
What really matters is ECK extras - we need to be sure that kolier will change ECK extras code, otherwise it will start raising WSODs. IMHO.

I'd gladly start/continue this integration but need to tie up some loose ends at work first.

@ OnkelTem do you think I should put this stuff in a separate branch? that way it is still accessible to those interested, I can give you access so you can work on it without having to post patches continuously, and I can continue working on bug fixes and creating new releases to make 2.x as stable as possible. I also have some new features that I wan to work on, so I was planning on creating a 3.x branch for that anyways. Maybe we can synchronize and release a 3.1-alpha with full multilingual support and some of the features I am planning to work on.

Thoughts?

@OnkelTem, lol you were a hundred percent correct. I thought locale was enabled, but it was not. Thanks for catching that.

ECK extras has been updated as needed : http://drupal.org/node/1705084#comment-6628390

@fmizzell : I saw you commited language into dev version, do you need any feedback on this?

@fmizzell, Sorry for delay with reply. Due to intensive load at work I can't dedicate enough time for contribution - so I can't no promise no plan when some work on ECK will be done, while having a branch which I responsible for means that I have to periodically sync it with the master branch. Key word here - periodically :)

I consider continue sending patches via issue queue (with standard reviewing workflow) is just fine for now.

It looks like this patch only allowed the "Multilingual support" property to be set when editing an existing bundle, not when adding a new bundle.

For a patch that would combine the forms so that it works when adding a new bundle also, see #1604598: Improved support for bundle options, configuration, and managing per-bundle fields