Integration of i18n and views.module = fix translatablity of views

It is i18n that should add views hooks. Not views adding i18n support.

I've been facing that trouble on the last two weeks, asking everywhere without solution and it's neither a views.module nor a i18n.module. There are two issues easy to solve:

- the content: needs that you play with Content selection mode on the i18n configuration page, what works best for me is Only current language and no language

- the block title: I've customized the views.module with an extremelly small hack which consists on changing on line 1067 (function views_view_block($vid)) the expression $block['subject'] = '$view->title'; with $block['subject'] = t($view->title); that forces your custom name to that concret view to pass through the locale translator of strings; form here on, after the first time you load that view on your optional language it will add an entry on the locale table which will ready to be translated (and it works!!!) :-)

BTW, it means that Mr. Bèr Kessels comment is very close minded since it's true that is i18n.module which has to face the translation of elements but it's very true that views.module is not open to internationalization since such an small improvement as the one I point here is not considered and means that views.module doesn't hooks with the locale.module which obviously demonstrates the lack of sensibility of the whole Drupal developement community to the urgent need to face seriously internationalization from the ground up. Just IMHO.

Without knowing whether this would have to be done by the i18n or views.module - may I also state that nice play between views and i18n would be lovely!

Best
.r.

Ber is right, it's i18n module the one which has to implement views hooks.

But about 'nice play', I've tried and seen no incompatibilities so far.

The title is «Integration of i18n and views.module» which is not the same as "fix translatablity of views".

So either make clear what you need *exactly* or leave this issue where it is.

If you think I am closeminded, because I think that i18n should add a hook_views_tables() you should read up on how views work.

So keep you voice down, don't call people names, and focus on the code/issues and technology. If you have a problem with me, say it to me, instead of in some public thread. Thanks.

Bèr

Dear Jose,

the one thing I see is that views show all translations of one text instead of just the one in the current language. I tried different 'advanced settings' in i18n and found they don't seem to make a difference for views.

Thanks for following this up
Best
.r.

Ok, Ber I sincerely apologize for my comment on your post, although the "closed-minded" attribute was related to your comment and not directly on you.

At least if you had read my post here you would have realized that I was saying something that is true about views.module: it didn't considered at all that the title of a view (the text to be displayed as a block title) didn't had the t() function, so didn't considered to be used under a multilingual environment, and for some one as me with such a small knowledge of PHP has taken me two weeks of frustration. And that's not related with i18n.module, simpley because this details reveals that views.module was not even L10n compliant... at least on that small detail in fact easy to solve but that has not being considered by the views team.

And to finnish that explanation it demonstrates that probably i18n.module doesn't require to add a hook_views_tables() since as long as I explain on my post on that issue i18n.module filters the content and displays the proper language of a view, and the simple addition of that t() funtion on the point indicated allows to translate the title through locale.module.

In any case I apologize again, since, no, I don't have anything on you. Sorry for the frustration on my comment :-)

Hello!

So, did pancapangrawit get an answer to her/his question in #7? I have the same problem, I want a view of blogs but I want the blogs shown to depend on the language chosen. Now, the advanced settings of i18n (display just current language, display all language, etc) do not seem to help unfortunately. I see all blogs! Or perhaps I am missing something ? Thanks in advance.

/boris-antoine

Well, the weird thing is that the home page (not frontpage, but "node") seems to be working fine, filtering the language of the nodes "promoted to the front page" in a correct manner (i.e. if I am in english version of "home page" I see only the english nodes, if I am in french version, I only see the french nodes, and so on). But I thought that "home page" was a specific view. The "frontpage" view provided with the views module does not display the correct behavior. So what is so special with the "home page", which can hold several nodes as it were a view and still handle languages in the correct way?

thanks in advance,
boris-antoine

I have the same problem, views.module is showing content in all languages and I don't know how to filter to only show the actual language.

Even if I pass the language code as argument to the view (i.e.: myview/es); how do I filter the posts based on the argument?

Thanks and I really hope there is fix for this soon!

A possible solution: create one view per language

I filter by content-type and an exposed filter by category term. As terms are shown by language this effectively leaves out posts with terms in other languages than the one you are using.

You see all terms while creating the view but only the right ones while using the view.

I hope this helps!

Alex, how do you make sure the same menu link in every translation goes to the view filtered for the selected translation?

I may have found a solution here...

Well, it makes more sense to post the patch here. If the way to make i18n and Views play together is to fix the db_rewrite_sql()'s as I'm proposing with this patch, then we have choice of changing either i18n orViews. Merlinofchaos may have good reasons to leave Views as it is. So what about patching i18n?

thank you David.
What a simple and beautiful patch :) it works for me.

I am working on a project that will depend heavily on views. Is there anything more that's needed than this patch to play well with il8?

I'm using the patch on some sites and it works well. You still need to clone your view for each language in order to have the title, header, footer, and other labels in the right language. So you may have views urls like "news_en", "news_fr", "news_es"...

Another thing you need to do is to create an url alias for each view. Without aliases, switching language while on a view won't translate the view's interface (title, header, footer, and other labels), although the view's nodes will be translated properly (thanks to the above patch). So I always create aliases similar to the following:

Url "news_en" aliased as "en/news"
Url "news_fr" aliased as "fr/news"
Url "news_es" aliased as "es/news"
and so on... And then, any menu item shall point to the right alias.

This aliasing trick is not so intuitive, but fixing that is another issue. ;-)

Hi you all. I've returned to that thread after having that trouble on some 4.6 project and having it again, exactly the same, on a 4.7 project, which means that in the meantime nothing has changed. And the issue is not the lack of integration between i18n.module and views.module (which could be better) but the poor support of the localization.module that views.module has, something that only its developers know why.

Translating the footer and header and title on views-generated pages just need to find the parts of the module that outputs that elements on a page and enclose them on t() functions. I've had that issue on displaying blocks views-generated and just using t() on:

$block['subject'] = t(views_get_title($view, 'block'));

then we can translate that block title to the different languages thru the localization.module. The rest should be easy. For example I've localized on view_ui.module at line 821:

'#default_value' => $view->page_header,

and at line 837:

'#default_value' => $view->page_footer,

what would happen if you change both with?:

'#default_value' => t($view->page_header),
'#default_value' => t($view->page_footer),

Maybe you could find here some solution, what it's true is that creating different views of the same page or block for every language (imagine one site with 6 languages, yes, that's the requeriment of some customer I got) is not logical, it would create such a list of views lists that you would go crazy. I don't have time to be more concrete by now, but I'll check that on footers and headers. On block titles it works.

BTW, the solutions of adding:

case 'node':

it's simply wonderful :-D Thanks David !

JordiTR: I understand that it could be very convenient to use t() here, and I know that some modules use t() in this fashion instead of implementing proper i18n support. However, I would not favor using t() on any database content... This kind of data can change often and tends to pollute the locale tables. Also, the locale module does not provide a very good workflow. The locale module is much more meant for translating "static" user interface than user-entered data.

But that's my personal take on this. You could still submit an issue on the Views module and see what others think about it. :-)

Now, I wish the one-line patch in #16 will get committed...

This means fixing all view localization (lang filter,view title, header, footer) issues by adding one line as proposed on #16 ?

Applied the patch in #16

However, if someone wants to work in introducint the i18n_views hook, it will be welcomed -- better as a separate task

Hi David. According your comments on #22 to my comments on #20 you're completely right, I agree, but, is there another way to do it? I would love to know it! :-)

It's true, foot comments on views, and other elements could change, but maybe not so much, at least title, or at least on the type of (corporate) sites I work on. In any case l10n module could be use to delete the old ones. It's just a question to be careful. I just hope to have a core i18n as soon as possible.

Unfortunately, the only easy ways to translate views (that I can think of at this moment) are your solution in #20 and mine in #19... ;-) Lets hope that all the recent i18n talks will lead to better solutions.

I had the problem that the views module did not translate the title of the view. I am using drupal 5.2 and views 5.x-1.6. Therefore I changed the code of the views.module in line 762
from: $title = $view->page_title;
into: $title = t($view->page_title);
to translate the page title of view.

David Lesieur's trick explained in #19 does not seem to be working anymore with my versions of views (5.x-1.6) and i18n (5.x-2.2). When I am on page "fr/news" and I switch to english, it brings me to "en/news_fr" instead of "en/news".

Anyway, it brings us back to square one: we need a real integration of those two modules.

is there progress in this area? Known solutions? Can we help with something?

no progress in this area guys?

Regarding Comment #28 above:

"I had the problem that the views module did not translate the title of the view. I am using drupal 5.2 and views 5.x-1.6. Therefore I changed
the code of the views.module in line 762
from: $title = $view->page_title;
into: $title = t($view->page_title);
to translate the page title of view."
This is the fastest method I've seen to fix this interoperability issue (for titles at least). It works great for me too, though I had to re-submit my views after the change.

Is this supposed to work with later versions of Views/i18n? I have Drupal 6.2, Views 6.x-2.0-beta4 and Internationalization 6.x-1.x-dev (2008-Jun-25) installed. The standard frontpage view (node) is language aware, but when I create a custom view as frontpage it no longer filters by language.
Edit: stupid me. Of course the 'node: language > current user's language filter will do this for me.

This issue is still not completely solved. Nodes can be filtered by language, but there are still no ways to translate a view's data (such as title, header, footer, empty text, etc.)

Marked #301020: Views internationalization : translation of views title as a duplicate.

in my opinion this update is critical

Any suggestions for a work-around for Drupal 6 & Views? It's kinda a show-stopper for me. .. thanks.

Using the latest 6.x-1.x-dev version of i18n, I was able to translate the views title, header, footer and empty text. The only bit that got me is that you have to render the view in a non-default language before the strings are available for translating.

@stella: Oh yeah, got it working too. Thanks for the tip!

How do we get terms to translate in views?

Any progress in taxonomy terms translation in views?

I've managed to get terms translated by extending views_handler_field_taxonomy with a pre_render function that translates the term names and could ultimately translate descriptions too. I used hook_views_data_alter(&$data) to change the handler used.

The patch here http://drupal.org/node/337348 (the one in the first comment) :

• Localises taxonomy terms in exposed filters ;
• Localises labels in exposed filters.

It does it using form_alter ; when it comes to displaying the exposed form I could not find a views hook that would let me change the data.

i think translated terms in views listing is essential

greenskin ... could you provide the code of your efforts?

thanks, josef

Well I've finally gotten around to posting what I've done to get around this issue.

I'm going to start by assuming you have basic API implementation knowledge for Views 2.

In the modulename.views.inc file I have two Views hooks implemented, hook_views_handlers and hook_views_data_alter. In the hook_views_handlers I specify the needed information for my custom handler, this handler also I have set with a parent of 'views_handler_field_taxonomy' so my handler basically will be appending to that already existing handler. In the hook_views_data_alter all I did was set the following code:

<?php
$data['term_data']['name']['field']['handler'] = 'custom_handler_field_taxonomy';
?>

Be sure that the handler name you specified in the hook_views_handlers is the as set in hook_views_data_alter.

Now inside of the handler file I have the following code:

<?php
/**
 * Field handler to provide simple renderer that allows linking to a taxonomy
 * term.
 */
class custom_handler_field_taxonomy extends views_handler_field_taxonomy {
  function pre_render($values) {
    foreach ($values as $key => $value) {
      if (isset($value->term_data_name)) {
        $t_name = tt('taxonomy:term:'. $value->term_data_tid .':name', $value->term_data_name);
        $values[$key]->term_data_name = $t_name;
      }
    }
  }
}
?>

There is probably a better, more efficient method to accomplish this, but this is a start and works for what I need.

Also, I should note that I've implemented this in a custom module so that when I update i18n I don't have to re-implement it again. The same code would work obviously though inside of i18n itself.

Is there any chance you could post this module somewhere for those who are only learning Views API? Or provide more hints as how to implement this (i.e. what goes to .module, what goes to .inc, .install and so on)?
There is just too much // example code here in the Views API documentation and some help to get started would be extremely useful...

The original issue is fixed. Easier to pursue new ones in separate issues. #346028: Translate taxonomy term names in Views looks right for the taxonomy term issue.

In case anyone wants to use the solution presented in #46, I've posted the module code in http://drupal.org/node/346028#comment-1642952.

subscribe