Multilingual front page and a "page not found" error

I have the same problem

I have the same problem

I'm having the same problem with the 6.x-1.0-beta1 version of i18n. I'm just beginning with drupal, but here's what I noticed after some digging.

The function i18n_init() in i18n.module is what turns on the "multilingual variables" functionality. However, it runs AFTER the bootstrap process, that is, after drupal_init_path() from includes/path.inc is called. That function is reproduced here:

function drupal_init_path() {
  print "DRUPAL INIT PATH\n";
  if (!empty($_GET['q'])) {
    $_GET['q'] = drupal_get_normal_path(trim($_GET['q'], '/'));
  }
  else {
     $_GET['q'] = drupal_get_normal_path(variable_get('site_frontpage', 'node'));
  }
}

Clearly then variable_get('site_frontpage', 'node') is returns the NON-MULTILINGUAL variable setting.

This seems to imply that variable_get() calls that happen before i18n_init() will be ignoring the multilingual variables.
So be careful about setting which variables are multilingual, since obviously some are safer than other.

I'll post in a few minutes once I find a workaround for this specific case.

I have indeed gotten this setting to be multilingual variable, works fine in my case... using i18n 5.x-2.3

Perhaps check that the node type you are using for each language has actualy gotten the language activated for it:
1. Edit the content type,
2. in the section 'Multilingual options' make sure to have "Normal - All enabled languages will be allowed." selected.

Other than this, can't think of anything else that wouldnt allow this to be working, if the variable shows as multilingual....

OK, so it took a bit more time than I expected, but here's a solution that seems to work for me in Drupal 6.
I have my own module, called "ewmod" that I use for all my customizations to the site.

In order to get the multilingual variables' "site_frontpage" to be recognized, there are 2 steps.

1. Make sure the following appears within your settings.php:
The first line (very important) ensures that the non-multilingual setting for site_frontpage is always blank.
The second simply tells i18n that site_frontpage is a multilingual variable, as described in the i18n handbook.

  $conf['site_frontpage'] = "";
  $conf['i18n_variables'] = array( 'site_frontpage' );

2. Having done this, add the following code to a custom module. (replace ewmod_ with whatever your module is called).

function ewmod_init() {
  // hook_init runs after all modules are loaded
  // and we have i18n as a prerequisite module

  // If ewmod_init runs before i18n_init, then call i18n_variable_init preemptively
  // There is no harm in this function being called twice
  global $i18n_conf;
  if(!isset($i18n_conf)) {
    i18n_variable_init();
  }
  // This is first called during DRUPAL_BOOTSTRAP_PATH, but because we added
  // $conf['site_frontpage'] = ''; to sites/default/settings.php,
  // The original call does nothing.
  // Now, we have ensured that i18n's mulitingual variables is enabled (via i18n_variable_init())
  // so calling this again will use the multingual setting for site_frontpage
  drupal_init_path();
}

This has only been tested on the 1 site I'm working on in Drupal 6, but I'll post back here if I find any problems.

As a bonus, here's how I get language-switcher to work properly on my home page, saying that the path "nouvelles" is the French counterpart to "news".
I'm using this for a front page based on Views, but since this is path based, this would work on anything.
Code shamelessly adapted from translation_translation_link_alter().

function ewmod_translation_link_alter(&$links, $path) {
  $translations = array(
    'news' => array('fr' => 'nouvelles'),
    'nouvelles' => array('en' => 'news'),
  );
  if ($paths = $translations[$path] ) {
    foreach ($links as $langcode => $link) {
      if (isset($paths[$langcode])) {
        // Translation in a different node.
        $links[$langcode]['href'] = $paths[$langcode];
      }
      else {
        // No translation in this language, or no permission to view.
        unset($links[$langcode]);
      }
    }
  }
}

Do I add this code to the i18n.module? Or do I make my own file in the i18n folder? Please be a bit more specific.

You should create a new module (call it piotrdesign), and define these functions within it.
Make sure to change ewmod_ to piotrdesign_ in the beginnings of the function names.

Please keep in mind that the code is written for Drupal 6, not 5.

Here is another fix to solve the problem of the $is_front-variable of the page template to not respect translations. Maybe this ist not that state of the art, but it works. Put this in your template.php file:

function _phptemplate_variables($hook, $vars = array()) {
  
  switch ($hook) {
    
    case 'page':
      
      // Set path dependant vars
      
      switch (arg(0)) {
        
        case 'node':
          
          if (is_numeric(arg(1)) && preg_match('/node\/(\d*)/i', variable_get('site_frontpage', 'node'), $matches)) {
            $nodes = translation_node_get_translations(array('nid' => $matches[1]));
            foreach($nodes as $node) {
              if ($node->nid == arg(1)) {
                $vars['is_front'] = TRUE;
                break 2;
              }
            }
          }
          
          break;
          
      }

    }

   return $vars;

 }

Can these functions be made into patches for i18n?

By the way, if you just want ex.com/ to return the english version of content, ex.com/fr/ to return the French version, etc., then you can actually just set the site_frontpage as 'home', set the path alias for all your front pages as 'home' and you will find ex.com/fr/ returns the correct French front page. You get nasty error messages when you save your front pages, but it works. I'm currently using it on a live site.

However there are drawbacks:

1. The nasty error messages whenever you edit one of the home pages. Why are they created, by the way? user warning: Duplicate entry 'home-en' for key 2 query: UPDATE url_alias SET src = 'node/6', dst = 'home', language = 'en' WHERE dst = 'home' in \modules\path\path.module on line 108.
2. A template called page-front.tpl.php is only recognised and used on the English front page, not the others.
3. You sometimes end up on ex.com/home or ex.com/fr/home during normal browsing. I don't really like that aesthetically. Ideally, I would not like to ever see ex.com/home or ex.com/fr/home pop up in the URL if I browse the site normally. So when I'm on the English homepage and I click "Francais" I want to end up at ex.com/fr/, not ex.com/fr/home (you can redirect it with Global Redirect, but it would be nice if Drupal just returned the right link in the first place).

So my "solution" is not viable long-term.

Eventually site frontpage should really be internationalizable in core, since content translation is in core. Perhaps at some point the whole of i18n_variables will get in there.

IMO we can't use #10. I think there 're other stuff that depends on $_GET['q'].
It's too late to work it on the theme layer.

Attached is patch from evolvingweb #7.

Also worth mention that I've created an issue for the locale block at #295626: locale_block: incorrect path for frontpage

Thanks a lot, this saved me from a lot of headaches! However, in order to really fix this problem we should be able to do without any changes to settings.php.

Since I'm running multiple sites I kept this fix in a separate module (only to be enabled in the concerned sites, where I also remembered to edit the settings.php-file). And then I can also make sure it doesn't get overwritten whenever I update the i18n-modules.

For anyone a little bit lazy or just not comfortable with making your own modules, here you go... a ready made version of what was explained in comment #7

Hello, Can someone please help. I uploaded the patch and enabled the module. I also edited my settings.php file but nothings has changed. Go to www.mjadrc.org and try to switch between 'English' and 'French' the French page returns 'Page not found.'

Thanks,

MT

The patch in #12 seems like a good idea. However, a solution needs to address page caching. When caching is enabled, hook_init is not called, so presumably the language-specific page won't be loaded.

Testing results for #12 with caching enabled would be useful.

If the patch doesn't work with caching, special handling of this variable in settings.php may be the only answer.

I don't think adding code to 'settings.php' is a good idea in general.

AFAIK normal caching should work with the patch #12, and yes aggressive caching will fail with it.

If it is to be made work with aggressive caching, I think that we'd have to hack core for that. My guess is we could put it at one of the bootstrap phases before the caching code is called. Maybe at the first variable_init

Opinions, guys ??

I tested the patch in #12 and it does work with normal caching but not with aggressive caching since that skips hook_init. I'm not really sure what the best practice is in such a case with aggressive caching?

I'm using beta6 of i18n and I think Jose solved the problem independently in there. Can someone verify...?

Problem was independently fixed in latest releases by Jose.

It can also be fixed by making the same alias for the page in all languages, for example make all the home pages get the alias 'home' and set 'home' as the front page. Now you get the correct page in all languages.

Was still having this issue in 6.x... turns out it's not a bug, but a matter of wrapping your brain around how drupal and i18n work together - with separate but related nodes for each version.

Thanks pieterbezuijen - your solution is best and simplest!

Confirm #22 worked for me in D6.17 + I18n.

Honestly, I still think that this is not much about "wrapping my brain around", rather about the fragility of I18n's mechanism.
It shouldn't be so hard and tricky to configure a multilanguage home page. After all, it is the site's most important node. I'd accept some rigidity here for the sake of usability.