Hi,

I'm using the i18n module to translate content. For my content-type I set Multilingual content to Normal - All enabled languages will be allowed.. Then in Home › Administer › Site configuration I set Content selection mode to Only current language and no language.

I was under the impression that this setting would hide content in a language other then the current language. But when I go to a certain node which is in English (and of which there is no translation into Dutch yet) and switch to Dutch via the translations block menu I will still see the English content. The custom menu however will only show links to translated content.

Pretty sure this is something I'm doing wrong but i can't figure out what. I've tried the other setting Only current language as well, to no avail. PErhaps I'm misunderstanding the whole concept of this setting?

Can someone PLEASE help me with this one?

Regards

Comments

kingandy’s picture

I believe the "content selection mode" determines what content is available in select boxes, such as a "menu parent" or "related node" type dropdown, or a taxonomy selection box. It doesn't affect access to the node itself.

jose reyero’s picture

Status: Active » Closed (works as designed)

The content selection options only apply for node listings (and other listings). It doesn't change access to individual nodes when you are seeing a single node.

fralenuvol’s picture

Could you suggest a way to restrict access to nodes according to current language?

Example of what I mean:
if current language is 'fr' only french translations of nodes will be shown, and further, if users try to access http://www.mysite.com/es/my_page they should be redirected to http://www.mysite.com/fr/my_page.

Any hint on how I could proceed?

kingandy’s picture

"if current language is 'fr' only french translations of nodes will be show"

Offhand, I imagine you could do this with a module that sits in front of the page-rendering process (maybe in hook_init(), or the !$may_cache clause of a hook_menu($may_cache) function for Drupal 5.x), checks the language of the current page (if it's a node) against the user's selected language and triggers drupal_access_denied() if the two don't match.

"if users try to access http://www.mysite.com/es/my_page they should be redirected to http://www.mysite.com/fr/my_page."

Unfortunately I believe the language code prefix is one of the main ways the system switches languages, so by visiting /es/my_page their interface would be switched into es. In fact the localization system is very much designed to facilitate switching between languages, rather than restrict it. I think this makes it unsuitable for the basis of a security system.

However I think it's important to make the distinction between Localization (the language prefix, which allows the user to switch their interface language) and Internationalization (the translation system, allowing nodes of different languages to be grouped together as "translations" of a single node) - they're related in that the available languages are managed in the same place but beyond that they're separate beasts. What you're trying to do here is use Localization to control access to Internationalization. In my opinion it would be more appropriate to use something more solid such as the Roles system - maybe set up roles into which the users are placed by an administrator, and then match these roles against the node's language as described above - or potentially even using the node_Grants system if you're familiar with it. (I'm not, but you might learn more from modules like Taxonomy Access or TAC Lite.) It might also be possible to automate role assignment based on initial language selection or some other criteria.

Unfortunately I don't have the time to do any direct work on this, but I wish you the best of luck...!

fralenuvol’s picture

Hi, thanks for your answer, I made some "homework", following your hints before answering you, in order to go a little further.

First a few words about the general strategy I am following:
Indeed I did not want to be as restrictive as involving roles, neither absolutely "restrict" access.

I just wanted, for logged users (for example french), to make sure that they keep browsing the site in their preferred language, even if they come from an external link (for example http://www.mysite.com/es/my_page), but at the same time I want to keep "lose" about access restrictions.
Indeed I don't know if this is the best approach, but it is the one that suits my needs at the moment.

I used hook_init() (I am using drupal 6.11) with my custom function in order to perform this task, and wanted to share this with you in order to know if this is the correct approach you mean.
What the function does: if a user calls an url corresponding to a node in another language, first check if there is an existing translation and shows it, if not, just redirect to the corresponding URL with correct language code (http://mysite.com/es/my_page -> http://mysite.com/fr/my_page, eventually implying "page not found" error, and this is ok for me).

I am not strictly a coder :-), therefore I copied some code "as is" from the global redirect module:


function mymodule_init() {
	mymodule_path_check();
}

function mymodule_path_check() {
	global $user, $base_root, $language;
	// Disable for not logged users
	if (!$user->uid) return;
	
	// Retrieve default language for both logged (user language) and anonymous (site language) users
	$language_default = language_default('language');
	
       $languages = locale_language_list(); // All enabled languages
	$user_lang = ($user->uid && $user->language && $languages[$user->language]) ? $user->language : $language_default;
	
	$user_prefix = db_result(db_query("SELECT prefix FROM {languages} WHERE language = '%s'", $user_lang));
	$url_prefix = ($user_prefix) ? ($user_prefix.'/') : '';


	$lang_prefix = ibaboo_get_lang_prefix();
	
	if ($user_lang && $user_lang != $lang_prefix)
	{
		if (isset($_REQUEST['destination'])) {
		  $destination = $_REQUEST['destination'];
		  unset($_REQUEST['destination']);
		}
	
		$path = $_GET['q'];
		
		// Get the Query String (minus the 'q'). If none set, set to NULL
		$query_string = drupal_query_string_encode($_GET, array('q'));
		if (empty($query_string)) {
		  $query_string = NULL;
		}
		
		// Do a check if this is a frontpage
		if (drupal_is_front_page()) {
		  // Redirect if the current request does not refer to the frontpage in the configured fashion (with or without a prefix)
		  if ($_REQUEST['q'] != $user_prefix) {
			$redirect = $base_root.base_path().$user_prefix;
			drupal_goto($redirect, $query_string);
		  }
		  // If we've got to this point then we're on a frontpage with a VALID request path (such as a language-prefix frontpage such as '/de')
		  return;
		}

		$request = trim($_GET['q'], '/');
		// Find an alias (if any) for the request
		$alias = drupal_get_path_alias($request);
    	if ($_REQUEST['q'] == $url_prefix. $alias) return;
		
		$translations = translation_path_get_translations($path);
		$node_translated = $translations[$user_lang];
		$path = drupal_get_path_alias(($node_translated ? $node_translated : $path));

		$redirect = $base_root.base_path().$url_prefix.$path;
		drupal_goto($redirect, $query_string);
		
		// Restore the destination from earlier so its available in other places.
		if (isset($destination)) $_REQUEST['destination'] = $destination;
	}
}