Last updated 5 November 2012. Created on 25 September 2008.
Edited by frederickjh, Kristen Pol, Jose Reyero. Log in to edit this page.

Here are some notes about integration with other contributed modules. This is about configuration and integration with other modules to use Internationalization features, but not about compatibility problems. If you have any issue about compatibility with other modules, please file a feature request on the issue tracker.


The Synchronization module works also for CCK fields.
There's no support (yet) for translating single fields into different languages.


The i18n blocks module is not compatible with Context. It won't break your site but just one of the modules will be able to handle the block selection. Change module weights so the one running later is the one handling the blocks.


AFAIK, the Pathauto module plays nice with Internationalization module. In addition to that, there are some features added into Internationalization module to provide different path templates for nodes depending on language.

Note: this won't work for bulk pathauto operations:

  1. Add pathauto variables to language-dependent variables in settings file, like:
  2. $conf['i18n_variables'] = array(
    'pathauto_node_pattern', // General pattern for nodes
    'pathauto_node_blog_pattern', // Pattern for blog nodes
    'pathauto_node_story_pattern' // Pattern for story nodes
  3. Set up different patterns for each node type/language on pathauto settings page (Like other variables, switch interface to set values for each language...)
  4. Play!


There is limited support for views strings translation using the included Views Translation module. Currently, it allows translation of views title, header, footer, and field names.
This is an ongoing work and it is a known fact that Internationalization views support is far from complete so better than posting (yet another, duplicate) "I want better Views integration" feature request, you can comment on the existing one, #64004: Integration of i18n and views.module = fix translatablity of views. Patches are welcomed though.
As node language is a core field in Drupal 6, filtering based on language is now supported by the views module itself so post any related issue to Views module.

Looking for support? Visit the forums, or join #drupal-support in IRC.


bigjim’s picture

One way to allow a view to be filtered based on the chosen language is to add the following code to the default of the Node Translation: Language Argument.

Add the Node Translation Argument to your view
Under "Action to take if argument is not present: "Choose "Provide default argument"
Chose "Php code"
Insert the code below

global $language;
return $language->language;

Now when you go to that page without an argument the chosen language is automatically inserted as an argument. THis of ocurse kills the display of language neutral nodes for that view.

I'm using Views2 to do this

mitjasvab’s picture

There is another more simple way with Views2:

- Enable the Views translation module
- Add a new filter to the view and choose from group i18n the i18n: Content negotiation

that's all.

Mitja Švab

morleti’s picture

Thank you so much for this great hint! Works GREAT!

prisonbreaker82’s picture

The last solution works like a charm! Thank you very much!

JBI’s picture

Lot of things an various adaptation in ubercart

I good sum-up seems to be :
seems a good sum up

JBI’s picture

Looking for feedback about how to have multilingual OG

I searched and read this support thread at it sems there is something fix since this summer.

Official way : To have an OG group node translatable, you must ensure the proper settings have been selected in the content type form:
* Multilingual support: Enabled, with translation. - This setting gives you a nice link in the local node menu options so you can readily get the job done.
* Multilanguage options:
o Options for node language: Pick the most appropriate setting for your setup.
o Extended language support: Pick the most appropriate setting for your setup.
o Synchronize translations: This is always an important part of the setup, for most purposes, I suspect, if you have a taxonomy, the Taxonomy Terms checkbox should be checked. The others, unless you require each field of the node to be synchronized between translations, I would leave them to their default states.

I hope this helps those who find this ticket.

NOTE: The Audience field is not included in the Multilanguage Synchronize Translations fieldset. This may still need to be reviewed.

But people seems not convince and are still using the crude get around

All my groups nodes are "language neutral" with no translation

any posts under that will be english or arabic (with translation)

all i need is to create a translated page that has the Page contents in the the other languae and link to it from the Group node

everyone joins a single Group node regardless of language. Awkward translation link for the Group Node as it would be a manually generated one and embedded in the Group node content in HTML

Other solution with OG's node in neutral that could deal with title and body of the OG node

For the title of the group use a taxonomy that can be translated

Body :

What did you do and how is it working for you ?

lpalgarvio’s picture

note: Dave Reid, a co-maintainer of Pathauto, has just stated that these variables do not apply to pathauto:

Posted by Dave Reid on October 20, 2010 at 10:03pm

That documentation is completely wrong and does not actually work properly with Pathauto. There are *already* per-language variables defined by pathauto.

the method is still valid for other variables though

Luís Pedro Algarvio
Drupal Linux DevOps