Hi you all.

Has anyone experienced with combining views.module and i18n.module? I'm trying to configure a site with separate menu blocks for each section created with views.module. Each section has its own menu according a specific vocabulary for defining a node inside a section. A views definition uses that vocubulary to set a block that I configure to respond only to the paths associated with the section.

Now I'm implementing internationalization to two languages (maybe three). Everything works but I would like that the module was translated to the proper language, according that the blocks display the title of the node (which obviouly is translated). Any idea?

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (fixed)

Unfortunately for 4.6 there is unlikely to be much you can do.

In 4.7, you can export your views, then create a small module which provides those views via hook_views_default_views(). Modify the code to put the translateables through t() and then translate via the normal interface. Once that's set up and you see them in the 'default' views list, you can remove them from your database. It makes editing your views a bit tricky but that tends to be a rarer case.

jorditr’s picture

jorditr commented
Category: support » feature
Status: Closed (fixed) » Active

You are telling me that there is no possibility at all to make i18n.module to translate the output of blocks created by views.module? If so, it sounds weird to me... In fact i18n.module is filtering the rendering of a page consulting the substituting paths to every node, module, block. It might be a way to do it.

And in any case: if it's not possible at all, shouldn't be a priority to find a way which allows both modules (that should be core) to interact among them?

Sorry if I reopen a closed issue, but I need to be sure that I have to give up. Is so important to me that not being capable to solve that issue could be a reason to look for another CMS solution and it would be sad to me after so many months invested on Drupal and see how efficient it is (except when we consider multilingual sites).

merlinofchaos’s picture

merlinofchaos commented

My best guess, not being familiar with the i18n module, is that i18n would need to make its data available to views; then you would have to modify each of your views to include i18n data so it could limit to the right translation.

More than that, tho, views tables themselves would need some kind of translation. I don't have any idea how to accomplish that.

One trick might be to create multiple views, and use PHP code in the block configuration section to turn blocks on and off based on language.

jorditr’s picture

jorditr commented

Thanks merlinofchaos, not being very procient on PHP you have given me some clue :-)

So, the point is that it could be interesting that views.module could list as filter the available languages and then build views addressed only to one concrete language among the ones active. Adding that filter could add some interaction between views and i18n. How can I try to make i18n.module data available to views? Which is the requirement.

Another possibility could be that i18.module could filter the views module output and map the pages that it points to the proper active language, but this should be asked on the i18n.module area.

jorditr’s picture

jorditr commented
Status: Active » Closed (fixed)

I've discovered I was making a subtle mistake that has taking me two weeks to discover... :-/

I close that issue.