i18n

I just pulled my hair out looking for what caused this, but eventually found it after scanning the module files. The issue was that overriding hook_theme_blocks wasn't possible in some theme. The version in the theme wouldn't get called at all, even after rebuilding the theme registry by clearing the cache. The culprit was the Block Translation module.

This is a follow up to the post "Creating a UTF-8 database to work with special characters".

When you want to move your database from one server/database to another one, you generally create a sql dump file from the source database using the mysqldump command and then do an import into the destination using the mysql source statement or via shell redirection (<).

This is just a heads up. When you make the connection on the destination server/database, specify the --default-character-set=utf8 option.

You end up with something like:

mysql -u user -ppassword --default-character-set=utf8 database < "dump.sql"

I am using the Drupal i18n module for content translation. Although it sometimes isn't as straight forward in usability as it should be, mostly there's a workaround for a specific problem.

I couldn't find one myself for a certain problem I was having with Drupal clean urls. So I decided to write a simple module for it myself.

On a typical site, you have pages like '/contact', '/help', '/faq', ... that you all want to share the same path for each language (like '/fr/contact', 'en/contact', 'nl/contact', ...). You also want to have a single access point like '/contact' that points to the right translation of that page depending on the current user language.

By default, this is not possible using the i18n module. At least, there's no great solution that I know off.

My workaround is the following. For each language I add the language prefix to the clean url. So when creating my page (or whatever other node type instance), I specify 'fr/contact' and 'en/contact' instead of '/contact'.
This works great for all language specific clean urls; 'fr/contact' points to the french version etc.

But I also want the language independent url, '/contact', to point to the translation of the page in the current language. For this, I had to write a simple module, from which the code is listed below.
This content checks all your clean urls and looks for urls that are prefixed with a language. Those urls get a menu item in the menu hook. This menu item triggers a callback which redirects the user to the page with the right translation. Problem solved!

The disadvantage of this solution is that the user isn't taken straight forward to the requested page, but is rather redirected to it. So the url changes ('/contact' becomes for example '/fr/contact'). Not a big problem for me though ;)

/**
 * Implementation of hook_menu().
 */
function multilingual_path_menu($may_cache) {
  $items = array();
  
  if (!$may_cache) {
  
    $sql = "SELECT DISTINCT SUBSTR(dst,4) as dst FROM {url_alias} WHERE ";
    $languages = i18n_supported_languages();
    foreach($languages as $key => $name) {
      $subsql[] = "dst LIKE '".$key."/%'";
    }
    $sql = $sql . implode(' OR ', $subsql);
    $result = db_query($sql);
    
    while($path = db_fetch_object($result)) {
      if(!drupal_lookup_path('source',$path->dst)) {
        $items[] = array(
          'path' => $path->dst,
          'title' => '',
          'callback' => 'multilingual_path_get_path',
          'access' => TRUE,
          'type' => MENU_CALLBACK
        );
      }
    }
  }

  return $items;
}

function multilingual_path_get_path() {
  drupal_goto($_GET['q']);
}

This is a little caveat for you in case you work with TinyMCE and the i18n module.

If you like to restrict the TinyMCE form to only appear on the node add and edit forms (node/add, node/edit/[id]), and you have spaces in your content type name, there's a slightly different drupal path 'behaviour' for the original node and the translated node.

The normal drupal path for adding nodes to drupal is node/add/[contenttype]. If the content type name contains spaces, the drupal path for adding a new node contains the content type name with spaces replaced by dashes. So you'll have something like node/add/blog-post if your content type is 'blog_post'.

That is only true for adding a new node that is not a translation of another node. If you say 'create translation' to add the translation for a node then the content type name in the drupal path hasn't spaces replaced by dashes but by underscores. So you'll have node/add/blog_post in our example.

Here is the code for the example 'blog post' content type. For completness' sake I have added the node edit case too.

<?php
if(arg(0) == 'node' && arg(1) == 'add' && (arg(2) == 'blog-post' || arg(2) == 'blog_post')) {
  return TRUE;
} 
else if(arg(0) == 'node' && is_numeric(arg(1)) && arg(2) == 'edit') {
  $node = node_load(arg(1));
  if($node->type == 'blog_post') {
    return TRUE;
  } else {
    return FALSE;
  } 
} 
else {
  return FALSE;
}
?>

I'm a Dutch speaking person. So sometimes I have to make Dutch websites. The Dutch language uses some special characters that are not used in English. I'm talking about tremas, umlauts, ... (ë, â, ...). These characters can turn up weird on your website.

As soon as you start seeing those appearing on your website, you might be sure it has to do with character sets and encoding.

And since your website is build upon a database, your database should be the first thing too look at finding the cause of your problem.

So the first thing I do when creating my database is to make sure it uses the correct character set. In MySQL this is done by issuing the following statement:

create database my_database character set utf8 COLLATE utf8_general_ci;