Handling missing translations

I use the following code in a custom module to redirect a display an appropriate message and show a 404 error page if a node is not translated yet...

/**
 * Implementation of hook_nodeapi():
 * - show 404 page if current language does not match content node language
 */
function ctmod_nodeapi(&$node, $op, $a3 = null, $a4 = null) {
  switch ($op) {
  case 'view': 
    // show 404 page if current language does not match content node language
    global $language;
    if (!empty($node->language) && $node->language != $language->language) {
      $msg = t('Sorry, the page %title has not been translated yet.', array('%title' => $node->title));
      drupal_set_message($msg, 'warning');
      drupal_not_found();
      exit();
    } 
    break;
  } 
}

This could easily be changed to redirect to the homepage instaed of displaying and error page... the following should do it:

    if (!empty($node->language) && $node->language != $language->language) {
      $msg = t('Sorry, the page %title has not been translated yet.', array('%title' => $node->title)); // needed when redirecting??
      drupal_set_message($msg, 'warning');
      drupal_goto(variable_get('site_frontpage', 'node'));
    } 

Redirecting to a translated node when available shouldn't be too hard either... I think you can lookup the node translation using translation_node_get_translations($tnid).

Hope this helps.. :)

I quite like that idea to lookup translations and redirect where possible, so I quickly implemented it... works great, especially as it solved another issue I had with frontpages not showing up correctly as well :)

Here's the code...

    // if current language does not match content node language
    global $language;
    if (!empty($node->language) && $node->language != $language->language) {
      // lookup translations for current node
      $translations = translation_node_get_translations($node->tnid);
      // redirect if there's a translation in the currently active language
      if (isset($translations[$language->language])) {
        drupal_goto('node/'.$translations[$language->language]->nid);
        break;
      }
      // else display a 404 page not found error.
      else {
        $msg = t('Sorry, the page %title has not been translated yet.', array('%title' => $node->title));
        drupal_set_message($msg, 'warning');
        drupal_not_found();
        exit();
      }
    } 

Yes, I'm using a "frontpage" version now as well...

/**
 * Implementation of hook_init():
 * - handle the case when the current language does not match content node language
 */
function ctmod_init() {
  if (arg(0) == 'node' && is_numeric(arg(1))) {
    $node = node_load(arg(1)); 
    // if current language does not match content node language
    global $language;
    if (!empty($node->language) && $node->language != $language->language) {
      // lookup translations for current node
      $translations = translation_node_get_translations($node->tnid); 
      // redirect if there's a translation in the currently active language
      if (isset($translations[$language->language])) {
        drupal_goto('node/' . $translations[$language->language]->nid);
        break;
      } 
      // else display locale front_page and display "page not yet translated" message
      else {
        $url = referer_uri() ? referer_uri() : 'javascript:history.go(-1)';
        $msg = t('Sorry, the page %title is not available in @language. ' . '<a href="!url" title="Return to the previous page">Go Back!</a>',
          array('%title' => $node->title, '@language' => $language->native, '!url' => $url));
        drupal_set_message($msg, 'warning');
        drupal_goto(variable_get('site_frontpage', 'node'), null, null, 307);
        break;
      } 
    } 
  } 
} 

I don't if something like this has a chance to go into the i18n module... I guess it would at least need some configurable options; any comments from someone responsible? :)

Really no plans for that into i18n atm.

Plus I think if you follow a link to some content, you are suppossed to get that content, whatever language it is in.

Such links should never be produced in the first place unless you do it on purpose. Besides, if the language is decided from browser settings, the same link can take two different users to different pages...

One use case to illustrate that: you find a result in a search engine, follow the link... oh, no such content but the frontpage.... that's not good IMHO, and breaks SEO. And there's a lot of people out there which feels comfortable browsing sites in mixed languages (better than not getting the content at all)

So I think if you guys want to address the issue, the right solution is never producing such a link, thus it is the language switcher which should be fixed, not the landing page logic (This causes other issues, like not being able to have a proper language switcher for a page, or the switcher taking people to the front page, which is kind of breaking the navigation context for most users)

So I think if you guys want to address the issue, the right solution is never producing such a link, thus it is the language switcher which should be fixed, not the landing page logic (This causes other issues, like not being able to have a proper language switcher for a page, or the switcher taking people to the front page, which is kind of breaking the navigation context for most users)

I agree, a good solution would probably be to fix the translation block and only display translation links to pages where the translation actually exists... possibly by just replacing the link-tag (<a href..>) by a span-tag (class="no-translation") for respective translation links...

Very interesting. I got here after a similar experience to the original poster. Executive summary of this post: eliminate duplicate content by returning 404s or at least working together with globalredirect. Remove links to untranslated content from language switcher block. It would be great if Jose or others could give their feelings on this so I'm setting status to active.

I see two problems with the current state of affairs (as 6.x-1.x-dev currently stands).

1. Duplicate content: depending on your language negotiation settings, ex.com/node/4 = same page as ex.com/es/node/4; OR for domain language negotiation, www.ex.com/node/4 = same page as es.ex.com/node/4. Either is considered bad for SEO.
2. Broken navigation on untranslated nodes with language switcher block. Regardless of your language negotiaton settings, the language switcher block will give links to content that looks like Spanish but is in fact English. In the above example, on ex.com/node/4, "Espanol" will link to ex.com/es/node/4 which produces exactly the same content (you get an anogulous experience for domain-based language negotiation)

Problem 1: Duplicate content is frankly a 404 issue. If node 4 is English, then ex.com/es/node/4 should be a 404 - it simply is not a Spanish node. This is how a path alias works (eg. if only the English alias ex.com/contact exists, then ex.com/es/contact produces a 404). In my opinion this is simple, there are no 2 ways about it and the current behaviour (provided by core) is in error (but, I'm very happy to listen to other opinions). If it's agreed that I'm wrong - then I hope that the issue can at least be addressed by globalredirect - avoiding duplicate content is the idea of globalredirect anyway. However I'm not able to test that as globalredirect currently has a critical i18n-related bug (#216271: Endless loop with translation (D6)). I agree with the original poster - the node number or path takes priority in determining the correct language (e.g. if node/3 is Spanish it must be accessed using the Spanish domain or path). Only exception: using browser language negotiation - this would have to be worked in.

Problem 2 - Jose is right that modifying the language switcher would break navigational context for most users - however it would be fair to say that the current behaviour is also totally confusing from a user's point of view. The suggestion proposed in #8 seems quite good - or just add a class of "no-translation" to the actual link so "display: none" can be used to hide these if desired. However that only works if problem 1 is fixed using globalredirect, because Google will see all the links.

I like the behaviour of node translation links: if there is a translation, the link appears. If not, it doesn't. Is there a reason why we are showing links to untranslated content in the language switcher block? If not, just turn it off like for the node translation links and the problem 2 is solved. This surely makes the most sense? If there is a good reason to show these links, then the solution to this problem is to make it a configurable option for the language switcher block, whether links to untranslated content are shown or not.

This issue is being dealt with by pathauto. See #201675: Redirect to version in native language. Yay!