After upgrading to i18n 7.x-1.5 and Variable 7.x-1.2 views are no longer filtered by language

This may be related to 'Language selection' module, though that is not advised for Views really (though it may work with proper settings).

Query rewriting has been improved and has become more 'picky' about which queries to rewrite (only the ones that are safe to rewrite) so this may be a side effect.

So I don't think we want to 'fix' this, better use any other method to filter your views. Views module has some proper filters for that.

I'll let this open so people can find it more easily.

Query rewriting has been improved and has become more 'picky' about which queries to rewrite (only the ones that are safe to rewrite) so this may be a side effect.

Well I don't see it rewrite anything anymore in my case. It's a total mess. It worked very fine with version 1.4 :(

Views module has some proper filters for that.
Which ones would that be ? Why did all worked fine in 1.4 ?

I want to add that I struggled a lot in the past with internationalization with drupal 6. Now it seemed finally to be more or less stable and working on each update I did. But it's again and again that issues occur. It's very though to have this working , while it should be very simple.

I set only: "Field Language:Current user's language"
This worked before in 1.4. What else should I do now with this new shiny 1.5 to fix ? :)

I'm not aware of any "language selection module" btw

The i18n module is 'Multilingual select', i18n_select

For what I'm seeing here, it seems that Views filter (Current user's language) was not working before and it was i18n_select doing that (which was not intended to do).

So please if Views' language filter is not working file an issue for Views. Unless it stops working only when enabling i18n, then we'll see.

@JGO,
And yes, i18n's query rewriting has been very much improved. If you don't like latest version, you can always downgrade.

I went back to 1.4. It did not work. I tried some other stuff, it did not work.
I resetted the complete view and started from scratch, boom it works again.

I updated all i18n modules to latest version, keeps working.
No idea what happened on that upgrade, because all worked fine before. Anyway after some struggling all seems to be ok somehow!

BTW if you improved it, that's a good thing! If it breaks things, not always a good thing :p Anyway apparently all works now somehow :)

I have exactly the same issue as reported by JGO.

After upgrading to i18n 7.x-1.5 in my Frequently Asked Questions page all questions and their answers in original language and two other languages are shown all together instead of question and answer per selected language.

In Views I had also a filter set to Field language: Current user's language.

I have tried everything without success. So updating to version 1.5 created a whole mess. Why? Before there was no problem at all.

I also downgraded to version 1.4 but it didn't help.

Please JGO, what did you eaxctly do to let it work again? With the same settings? If I understood well, I'd have to delete my whole FAQ's thing and restart building it from scratch?

Latest version of i18n updates includes a full cache refresh, which may not be a good idea because it seems it's unveiling some unrelated issues on other modules.

Well after recreating the view. I went to Filter criteria > Add > Content translation: Language > Current user language
This step is crucial for it to work. But like I said , I also recreated the view.

I have the same problem, except I'm not using Views. It's a custom SQL query built using DBTNG as follows:

    $query = db_select('node', 'n');
    $weight_alias = $query->leftJoin('faq_weights', 'w', '%alias.nid=n.nid');
    $query->addTag('node_access')
      ->fields('n', array('nid'))
      ->condition('n.type', 'faq')
      ->condition('n.status', 1)
      ->condition(db_or()->condition("$weight_alias.tid", 0)->isNull("$weight_alias.tid"));
    $query->addExpression("COALESCE(w.weight, $default_weight)", 'effective_weight');
    $query->orderBy('effective_weight', 'ASC')
          ->orderBy('n.sticky', 'DESC');
    $query->orderBy('n.created', 'ASC');

    // Only need the nid column.
    $nids = $query->execute()->fetchCol();
    $data = node_load_multiple($nids);

As you can see I'm adding the "node_access" tag on line 3.

This used to work fine using i18n 7.x-1.4, but as soon as I upgraded to 7.x-1.5 all nodes from all languages are being displayed. I cleared caches, etc but no joy. I also tried it on a freshly installed site (just in case it was an upgrade issue) and have the same problem. Any ideas on what I'm doing wrong?

@stella,

In latest version what we do differently, bug fixing aside, is some more query checking to see whether it is suitable for altering and that includes checking all the field names have proper table/alias prefix (otherwise we cannot safely join other tables)

Your query seems to have at least one field without table prefix, 'effective_weight', so maybe it's related to that.

Well I had the same problem. I had all my Commerce products and blog posts in all languages showing up in every language.

After some reading here, I went to the views configuration and manually added a filter "translation language = Current user's language", which solved the problem.

This should have been communicated to people who are upgrading this module since it seems to be implemented on purpose.

Your query seems to have at least one field without table prefix, 'effective_weight', so maybe it's related to that.

Not sure how I can give that field a table prefix considering that it is an expression added using the addExpression() function.... thoughts?

@stella,

Oh, right, I missed that, but it doesn't seem to be the problem anyway. I've been checking your query and the part that is 'failing' is here:

function i18n_select_check_query($query) {
...
  // Check all the conditions to see whether the query is suitable for altering.
  foreach ($query->conditions() as $condition) {
    if (is_array($condition)) {
      // @todo For some complex queries, like search ones, field is a DatabaseCondition object
      if (!isset($condition['field']) || !is_string($condition['field'])) {
        // There's a weird condition field, we won't take any chances.
        return FALSE;
      }
   }
 }

For that specific condition (Array, 3 elements):
field (Object) DatabaseCondition
value (NULL)
operator (String, 7 characters ) IS NULL

The idea is we don't alter queries we don't know, though I agree the checking could be improved, maybe checking conditions recursively (that condition contains an array of two OR conditions).

So we have two options here, improving the i18n_select module to handle more complex queries or maybe easier, since yours is a custom query, just add the language condition there.. ?

I could add the language condition I suppose. Would it just be as simple as adding:

$query->condition($table_alias . '.language', i18n_select_langcodes());

What is the advantage of this new checking mechanism ? Were there any problems before ?

@JGO,

Yes, there were random queries failing (fatal error) for reasons like not having the table name for every field, then crashing when you join another table or add a field condition.

So let's say now the bugs we see are 'query not having language condition' instead of 'fatal error...'

@stella,
Since the language field is in the node table, I guess your query would need a simple:

$query->condition('n.language', i18n_select_langcodes());

So:

- For views not filtered by language, use Views' language filter. File an issue for Views if it's not working. Filte a feature request for it if you want a better one.

- Our 'Multilingual select' module is not intended for views and it doesn't filter views as a default. Though you may have the option of trying it for your Views (remove 'views' from the list of excluded tags). It may work or not, just it is not intended for views, so 'not working for views' is not a bug here (though it breaking views queries with fatal errors would be)