Views.module is not compatible with i18n

Hi:

Did you find any solution for this?
I have the same problem, =(

Thanks in advance.

Unfortunately I've had no time to look. I'm not at all familiar with i18n.

As mentioned above, the Views module does not filter the nodes by language when the i18n module is enabled. This means that all the nodes from all the languages are displayed, which is not desirable on a multi-lingual site.

The i18n module provides a table 'i18n_node' which maps nodes with their translations. So to know the language of a node we can use:

SELECT language
FROM `i18n_node`
WHERE nid =...

We should still find out what is the current language and then compare the two.

Maybe the author of the i18n module could help.

Hope this can help, it would be really great to have Views working with i18n. By the way, thanks for the great module, I just installed it and apart from this issue it is really remarkable.

Fred.

Ahhh! In fact, my policy is that information like that from modules must be provided by the module, so i18n needs to supply a filter that people with views can use. Maybe I've been overcomplicating the issues with i18n.

Worst case scenario is that someone could write an i18n module that makes this data available.

The i18n module usually handles the language filtering through hook_db_rewrite_sql(). I noticed that Views passes 'node' on its db_rewrite_sql() calls, so I edited i18n_db_rewrite_sql() to support 'node' in addition to 'n' as a primary table (see the patch), et voilà! At least it seems to work according to my [very] quick test. Now, should i18n be modified as such, or should Views use 'n' as the primary table in its queries? The Drupal core seems to always use 'n', so should Views do the same?

I don't think i18n should implement Views' hooks. That would force the site's designer to manually take care of the language filtering in each of his views. And more importantly, allowing i18n to automatically do its usual filtering ensures that nodes are filtered in accordance with its sophisticated "Content selection mode" (see administer > settings > i18n > advanced settings).

Subscribing

Ahh! The reason the views module uses 'node' as the primary table is for consistency. It always uses the full name of the table, and originally it *did* special case 'node' to 'n' but that was very ugly and was causing me problems in debugging.

I'm bringing the ball into i18n's yard. We'll see what happens. ;-)

Hi all,
I am facing the same issue of this thread. I am trying the patch, but I would like to propose to your attention a different solution as well. Why not adding a new filter like "i18n: language"? This might be even a more powerful feature to merge such two important modules.
Thx,

Such a filture would have to be added by i18n using the views API -- which would undoubtedly be very easy. Could likely add current language and 'by language' rather easily.

Just to be clear, it is the policy of Views to not include support for modules that are not in core.

If a contrib module needs that support, the patch must be submitted to that module, not Views.

then i18n should be a core module for next major drupal release. I think they are working on it.

I think views should have to report only current language or whatever is specified in the i18n settings. if you have a language filter to override it... perfect.. but it makes sense to act by default as the core taxonomy node view for example.

Uhh, Drupal core doesn't have any language settings for a node; that is completely an i18n module definition. In order for views to be able to act on that, it either needs to properly rewrite the views query OR it needs to export its data to Views so that people using i18n can utilize that data, whichever works better.

In either case, as I said before, it is the policy of Views that, because it makes it possible for all modules to make their data available to Views, it is the policy of Views to only support Drupal Core features and data, and not other modules. Thus I retain and reiterate "won't fix" status.

I have come across the same problem, as I'm sure many others would have. It seems that for the past 3 months both parties refuse to include the fix in their module considering it the responsibility of the other party. Can anyone recommend a patch so that we can carry on and fix it ourselves? I'm a bit of a newbie so woudlnt know where to begin, but if someone can mention what code to put where I would appreciate it,
cheers,

I just figured out what to do with the patch file above :P
did i understand correctly, but all that needed to be done is add a "case 'node':" and it works!

If i18n maintainers won't patch their module to accept 'node' as well as 'n' in their db_rewrite_sql routines, that is both inane and asinine at the same time.

There should be a standard way of naming tables in queries, so hook_db_rewrite_sql() could be safely implemented by any module (including, but not limited to i18n). I don't know if such a standard exists, but if not, it should. And both modules involved in this (imho kind of stupid) argument should comply to that standard.
So, this is an issue that should be solved in "core drupal api", otherwise this could happen again anytime between any other pair of modules.

I will insist until the end of the earth that calling the 'node' table 'node' is perfectly valid.

The core Drupal API only cares if the primary field is 'nid' and doesn't care at all what the primary table is.

It seems the patch in #5 has been committed in i18n after all...