When a view is embeded in a page, it runs with the content selection mode set to displaying pages in current language/no language only. It ignores the content selection mode set in the settings page (presumably, this is because 18n overrides the content selection mode in hook_init).

CommentFileSizeAuthor
#13 i18n.patch2.34 KBjax
#11 i18n.patch2.19 KBjax
#9 i18n.patch2.96 KBjax

Comments

jose reyero’s picture

jose reyero commented
Category: bug » feature
Status: Active » Closed (duplicate)

Yes, views queries cannot be rewritten, there's some other issue abt it...

About views integration (wip), follow up here, http://drupal.org/node/280407

Alice Heaton’s picture

Alice Heaton commented

I've updated to the latest nightly, and this seems to be fixed - at least for the case where content_selection mode is off (probably linked to this fix : http://drupal.org/node/283839 )

Thanks :)

jax’s picture

jax commented
Status: Closed (duplicate) » Active

I'm reopening this since the issue referred above is marked as fixed and it still does not work.

The issue:

  • I have a content type "News" which is available in English and Dutch. I translate each of the news items.
  • The "Content selection mode" is set to "Current language and language neutral".
  • I create a view "latest_news" which show the news nodes in a block view.

Now, when I watch a page with the block it shows all the nodes in stead of only the nodes that are valid under the "content selection mode". I would think that it should respect that setting and only show the English nodes when the interface language is English and the Dutch ones when the interface is in Dutch. This could either happen automatically or i18n could add a filter to views that is something like "Respect content selection mode".

TheRec’s picture

TheRec commented

Helllo,

Maybe you should look in the "Filters" part of your view, add a "Node translation" filter and set it to "Current user's language" (and maybe "No language" if you want "Language neutral" nodes to be displayed), I think it does what you intend to do. I hope this helps you. I think that before (with Views 1.x) it was doing it automatically, but that's great because it gives you even more power over what you want to show :)

jax’s picture

jax commented

No, "current user's language" is not what I'm looking for since it should work for anonymous users and users that haven't set their preferred language as well. The issue here is purely connecting the negotiated language and the content language negotiation with the view shown on that page.

jax’s picture

jax commented

Okay, if you add

function i18n_views_query_alter(&$view, &$query) {
	global $language;
	$where['clauses'][] = "node.language = '$language->language'";
	$where['type'][] = 'AND';
	$where['args'] = array();
	$query->where[] = $where;
}

to i18n.module you already have "Only current language". I'll try to roll a patch tomorrow that nicely obeys the different content negotiation modes based on i18n_db_rewrite_sql().

Alice Heaton’s picture

Alice Heaton commented

@Jax :

PLEASE don't use views_query_alter ; this will interfere with other views language negotiation filters such as Select Translation.

There is not one algorithm to deciding which language to pick - i18n content selection implements one ; select translation implements it differently. It should be up to Views users to decide which algorithm they want to use ; it shouldn't be imposed on them because they needed some other i18n features.

To do this properly, i18n should implement a Views filter entitled 'i18n content selection' or something similar ; not aggressively rewrite all queries.

Please, please, please consider my query ! I don't have time right now, but give me a month or two, and I'll write that filter myself if it helps !

jax’s picture

jax commented

Hi, I already wondered if rewriting the query was the best way and considered using a filter. If I already knew how to implement a views filter that would have been my first option. I also already figured that just implementing views_query_alter without any other options might not be the best idea. I'll abandon the idea of a patch doing the views_query_alter and will try the filter approach.

jax’s picture

jax commented
Title: views embeded in page do not respect content selection mode » views embedded in page do not respect content selection mode
StatusFileSize
new i18n.patch2.96 KB

Here is a first version of a "content negotiation" filter. There's some more cleanup and fine-tuning to do which I will probably do tomorrow.

Alice Heaton’s picture

Alice Heaton commented

@Jax : Thanks !!! You were pretty quick at making this filter given you'd never done one before !

Code looks good to me :) Some suggestions :

1. The query object doesn't always name things the way you expect them ; Since this is a node filter, and you use the node table it's pretty safe to name it directly, but in general it's best to ask the query what it wants the table called. You could do something like :

  $table_alias = $this->query->ensure_table('node');

and then use $table_alias as your table rather than 'node'. This is the way it is done, for instance, in the 'ensure_my_table' function of views_handler (in /modules/views/includes/handlers.inc , line 414 )

2. The first parameter of the 'where' call represents a group. This feature is currently unused, but my understanding is that it will be used in the future to create 'OR' queries ; users will be able to set the group of each filter, and then combine the groups with logical operators. So the correct thing to do is :

$this->query->add_where($this->options['group'], $where);

This is what is done in the query code of views_handler_filter for instance (in /modules/views/handlers/views_handler_filter.inc , line 582)

Hope this helps !

jax’s picture

jax commented
Status: Active » Needs review
StatusFileSize
new i18n.patch2.19 KB

And here's a patch providing a content negotiation filter with the suggested changes in #10 and a nice cleanup.

jose reyero’s picture

jose reyero commented
Status: Needs review » Needs work

The patch looks good. However I'd like to have all the views related stuff in one place, so you can always disable it while keeping all the other i18n features working.

Sorry, but views are such monster objects, I'm still scared which other side effects may have to enforce views features on the module core.

If you could change it to apply to i18nviews module instead of i18n I'd just get it in.

Thanks.

jax’s picture

jax commented
Status: Needs work » Needs review
StatusFileSize
new i18n.patch2.34 KB

This is the same patch but for the i18nviews module. It is against i18n-beta4 so I'm not sure if it applies to head. I've tested it briefly and it seems to work.

jose reyero’s picture

jose reyero commented
Status: Needs review » Fixed

Committed, thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

pkej’s picture

pkej commented
Version: 6.x-1.x-dev » 6.x-1.0

This seems to be missing from 6.x-1.0. At least after upgrading to that version (from a patched earlier version) the i18n-content negotiation filter disappeared, I can only select filter methods from "Language", which isn't adequate for a scenario where most content is available in one language but not in another.

I don't know if it is proper to set this issue to active, but unless I see someone commenting here within the next few days (Jose preferrably) I will set it to active.

jax’s picture

jax commented
Status: Closed (fixed) » Active

The whole i18nviews folder seems to be missing from the 1.0 release.

jax’s picture

jax commented

Jose, what is happening with i18nviews?

Update: I just noticed that this functionality now works when you choose "Current user's language". So, this is no longer necessary.

jose reyero’s picture

jose reyero commented
Status: Active » Closed (works as designed)

Yes, the i18nviews module was left out of the release as it was by no means production ready. You can find it in the -dev releases.