Date field language handling problems

Date fields should not be translatable.

I ran into the exact same problem yesterday afternoon. Any solutions?

I am experiencing the same issue, with 7.x-1.0-alpha2. It completely blocks our multilingual site, where some pages have a translation, but not all (the pages in "undefined" language don't show up).
Here is an example of flawed SQL query, with the faulty part in "strong":

SELECT node.title AS node_title, node.nid AS nid, node.language AS node_language, field_data_field_date.delta AS field_data_field_date_delta, field_data_field_date.language AS field_data_field_date_language, field_data_field_date.bundle AS field_data_field_date_bundle, field_data_field_date.field_date_value AS field_data_field_date_field_date_value, field_data_field_date.field_date_value2 AS field_data_field_date_field_date_value2, field_data_field_date.revision_id AS field_data_field_date_revision_id, 'node' AS field_data_field_date_node_entity_type
FROM 
{node} node
LEFT JOIN {field_data_field_date} field_data_field_date ON node.nid = field_data_field_date.entity_id AND (field_data_field_date.entity_type = :views_join_condition_0 AND field_data_field_date.deleted = :views_join_condition_1)
WHERE (( (node.status = '1') AND (node.type IN  ('news')) AND (node.language IN  ('fr', 'und')) <strong>AND (field_data_field_date.language = 'fr')</strong> ))
ORDER BY field_data_field_date_field_date_value ASC
LIMIT 5 OFFSET 0

also commenting those lines out as a temporary solution.

We had the same problem. Just removed the where clause in hook_views_query_alter, untill there's a solution:

change 2 ofcourse, depending on your conditions:
unset($query->where[0]['conditions'][2]);

This is a major bug, let's keep it active. I use the same workaround than in #7.

Marked as a duplicates
#1087846: Views with date field don't show nodes than have a different language than the curent user language
#1103982: Adding a Date field to Fields in View adds a Language Filter in where-clause.
#1082404: Date field not working in Views when Locale activated

Still not fixed in 7.x-2.x-dev (2011-Apr-06 )

subscribe

+1

If your date fields language is set to 'und' then there is a workaround using the query settings of the specific view.

Choose Advanced -> Query Settings -> Remove check from 'When needed, add the field language condition to the query.'

The mentioned condition from the issue description is no longer added to the query:

field_data_field_date.language = 'en'

This works with the following versions:
Views 7.x-3.0-beta3
Date 7.x-2.x from today.

Did some digging into how translation is being handled in D7 and this is a can of worms. Date fields should not be translatable, but in the current Field UI, any fields you create will automatically become translatable. The only way to keep them from being translated is to install the Entity Translation module and go into them and mark them as not translated. And if they are translatable, the Views module will join in the language column. So that is all outside the control of the Date module.

And funny things happen if you start out with a site that does not use Content Translate and later turn it on. Fields created before you turn it on will have 'und' in the language column, fields created after you enable it will have 'en' (or whatever your site language is) in that column. So it is pretty easy to end up with multiple possible language values.

Not quite sure yet how to handle this if you have fields with multiple languages.

This is a combination of some oddities in the way translation works and the way that Date was handling 'additional fields'. I just committed some changes so the Date module is no longer adding the language field into the query. That should help. Views may still add the language field to the view. You can turn that off by going to the 'Advanced' options, edit the 'Query settings', and uncheck the box to add the language field to the view.

See if those two changes fix your problems. I just made the change to Date module, so be sure you pick up latest Date -dev version from git.

I still think I should be able to force the date field to be untranslatable, but that is out of my control and I think these other changes will do enough to fix this problem.

Thanks for the solution in #14 - it works for me :)

Moved issue about granularity, timezone conversion and views filter problem to http://drupal.org/node/1135558

@anschinsan, if you don't open a new issue for that it will get lost. Just erase your comment here and copy it into a new issue.

We updated to latest 7.x-2.x-dev and the where condition is still there.

Changing the views advanced language settings doesn't affect the query at all.
Also i'm confused the "und" (undefined) language case is not covered here...

so no solution here.

BTW: is it guaranteed that all nodes have a field row? Currently the added language condition in the query WHERE section changes the LEFT JOIN to the functionality of an INNER JOIN where nodes without a date field row will disappear.

Also in single language mode the language condition gets added to the query (which i consider wrong).

The language condition is not being added by the Date module. I don't know where you are seeing a language condition getting added, but I do not see that.

KarenS: Language condition added: I'm not addressing date code, but the resulting query. So i don't know who's responsible for that...

Ohh.. i see, advanced settings per view to remove translation. That works.

So I can mark this fixed??

Karen, right we have a workaround.

However i think we still should dig deeper and try to define the field as untranslateable.

http://api.drupal.org/api/drupal/modules--field--field.multilingual.inc/...
Obviously we can set the date untranslateable somehow, see:

function field_is_translatable($entity_type, $field) {
  return $field['translatable'] && field_has_translation_handler($entity_type);
}

See here:
http://api.drupal.org/api/drupal/modules--field--field.multilingual.inc/...
* The available languages for a particular field are returned by
* field_available_languages(). Whether a field is translatable is determined by
* calling field_is_translatable(), which checks the $field['translatable']
* property returned by field_info_field(), and whether there is at least one
* translation handler available for the field. A translation handler is a
* module registering itself via hook_entity_info() to handle field
* translations.

However the fields UI always sets fields as translateable:
http://api.drupal.org/api/drupal/modules--field_ui--field_ui.admin.inc/f...

Instead of adding an alter to the ui, i think we should implement hook_field_create_field.
http://api.drupal.org/api/drupal/modules--field--field.crud.inc/function...

Thus we'll need to field_update_field() with $field['translatable'] = FALSE set.

Finally this is a drupal 7 core limitation... In discussions about this we all agreed that drupal should merge the values (e.g. translatable and also cardinality and default value) from the field type definition. This wouldn't change the function API but add new possibilities in field definition data structure.
http://api.drupal.org/api/drupal/modules--field--field.info.inc/function...
A hook_field_create_field_presave is also missing and might be an option. However it wouldn't be that clean as a per-fieldtype definition.

subscribe

See #1164852: Inconsistencies in field language handling where I have been trying to get clarification about how to handle translations. There is a lot of confusion around this.

Changing the title, we'll make this the key issue around problems with the translatable field.

I managed to miss the is_translatable() hook. Looks like that makes sense at least, we definitely don't want date fields to be translatable. Would someone like to make a patch to add that and and update hook to fix the data?

Also, not sure what #23 is suggesting we do about fixing the Field UI, I don't plan to fix core bugs here if there is working going on to fix them in core.

Never mind comment #26, field_is_translatable() is not a hook. I still don't think there is any way for Date to say that date fields should not be translated.

KarenS
That's actually right. We're thinking of escalating this to the core team and try to bring this feature into Drupal 8 / 7.
At the moment you only could add a form submit function on a date field and resave the definition with a changed translatable FALSE setting.
While it is basically possible it's still a workaround caused by drupal core limitation.

Let's see what the discussion brings. I'll update the issue once we have more inputs.

subscribe

subscribe

The inconsistencies in core that made some fields translatable and some not has been fixed. If you use the Entity Translation module you can check or uncheck date fields to make them translatable. There is work going on in core to make this stuff work better in D8, with no idea what/when it will get done or if it would be backported to D7.

I'm not sure after all that Date should make itself untranslatable since the end users can control that with Entity Translation.

With all that said, I feel like there is nothing more this module can be expected to do and I'd like to close this issue.

Flagging the translation issues.

subscribe

You are subscribing to a fixed issue, nothing to subscribe to. Plus there is now a 'Follow' link you can use instead.