localizerblock: it just doesn't work for me...

Does it mean that I can't change the title of, for example, 'user login' block?

In Drupal5 you have an option to change block header of any block, e.g. in admin/build/block/configure/user/0 you can override default title of 'User login' block. I was wondering if there is any way to localize this type of user input.

My next question: I've ported 'site_map' to D5 yesterday, and I've installed it on my website to show all site menus. I have 'ru' and 'eng' locales. My navigation menu is translated, but sitemap shows UNtrunslated menu titles and translated menu elements. I'm not sure why it is happening so, the code to create sitemap menu is:

function _site_map_menus() {
  if ($mids = variable_get('site_map_show_menus', array())) {
    $menu = menu_get_menu();
    foreach ($mids as $mid){
      $title = $menu['visible'][$mid]['title']; // <---- this remains untranslated
      $menu_display = _site_map_menu_tree($mid, $menu); // <----- translated
      $output .= theme('box', $title, $menu_display);
    }
  }

  return $output;
}

is it a problem of localizer or of a sitemap?

Thanks for your help.
I've fixed that by

if(module_exists('localizermenu')) {
    $translation = localizermenu_translatemenuitem($mid);
    $title = $translation['title'];
    } else {
     $title = $menu['visible'][$mid]['title'];
    } 

but I've tried to find the indirect call to hook_menu and I didn't find it... I can't understand why all menu elements are _translated_, and title is not.

I've created a block, changed it locale to 'english'.. but I see it on russian locale too.
I've tried to debug localizerblock_db_rewrite_sql():

  $applylocalizer = ($primary_table=='blocks');

  if ($applylocalizer) {
    var_dump($query); <---- // I never see it... so no query rewriting at all
    $nodeslocales_assql = localizer_get_nodeslocales_assql();
    if($nodeslocales_assql) {
      $blid = "CONCAT(b.module,'-',b.delta,'-',b.theme)";
      $sql['join'] = "LEFT JOIN {localizerblock} loc ON loc.blid=$blid";
      $sql['where'] = "loc.locale IN (" . $nodeslocales_assql . ",'-') OR loc.locale IS NULL";
    }
  }

I've patched block.module, now db rewriting works but multilingual blocks still are showed on all languages...
SQL that the rewriting function gets:

string(220) "SELECT DISTINCT b.* FROM {blocks} b LEFT JOIN {blocks_roles} r ON b.module = r.module AND b.delta = r.delta WHERE b.theme = '%s' AND b.status = 1 AND (r.rid IN (%s) OR r.rid IS NULL) ORDER BY b.region, b.weight, b.module"

returns:

array(2) {
  ["join"]=>
  string(83) "LEFT JOIN {localizerblock} loc ON loc.blid=CONCAT(b.module,'-',b.delta,'-',b.theme)"
  ["where"]=>
  string(46) "loc.locale IN ('en','-') OR loc.locale IS NULL"
}

I've tried simple blocks, menu blocks... for simple user created blocks with 'eng' or 'ru' locale the localizerblock doesn't work at all. For menu blocks it works strange, it hides my website navigation on 'eng' locale, though I've set 'any' locale in block settings.

I've rewritten localizerblock.module to work in 'localizervars way', I mean every block have multilingual title and block of 'block.module' (box) also have multilingual body. I had to patch block.module to make it work, so I'm not sure if anyone need it :) I'll test it a bit more and upload tomorrow as a patch.

http://russianwebstudio.com/other/localizerblock-5.x-0.1-dev.rar

I've attached my version of block.module and patch against cvs version.

I'm not sure that this version of loc_blocks module can completely replace the old one. May be someone needs to hide some block on some locale, but I think he can use i18n_get_lang() in 'Page specific visibility settings' (Show if the following PHP code returns TRUE (PHP-mode, experts only).) + my version of loc_blocks to override titles and box bodies

>i18n_get_lang()
You shouldn't use this function.
It is called only to determine the language on the first access.

Use instead localizer_get_nodedefaultlocale();

Ok. In this case I need to change loc_profile and loc_vars too

It seems to me that the patch is reversed.
The code to add is reported to delete.
Am I wrong ?

Yes you are right :) I've attached correct patch

>i18n_get_lang()
You shouldn't use this function.
It is called only to determine the language on the first access.

Use instead localizer_get_nodedefaultlocale();

Ok. In this case I need to change loc_profile and loc_vars too

It seems to me that the patch is reversed.
The code to add is reported to delete.
Am I wrong ?

Yes you are right :) I've attached correct patch

oops, double post. The last post has correct patch

Mm, it works for me, I've tested it on block.module boxes and my website navigation menu.

I'm not sure that this approach will be ok for menu items - pretend that you need to translate 20 menu items on 4 languages.. huge amount of page reloads.
But, if we implement some kind of 'translation console' for mass translations, it would be ok.