Make the active menu item (and every link) works in a translated version.

I spent several ours working on this issue and came to the conclusion that the solution is not as simple as wundo proposes. The reason is, that the menu-object, dynamically generated and stored in $menu, stores (besides a lot of additional stuff) the relation between path (as you defined in the menu-administration) and menuID. During setup and theming of the page, the menu-object is queried several times, e.g. to identify visibility, activity etc. of content elements and naturally to code the html of the menu itself.
As I understood, the menu-object tries to store the menupath in the normal form 'node/XXX', i.e. drupal tries to resolve aliased pathnames. If this cannot be done, the alias-string is stored.
In the case when you define an aliased nodepath (e.g. 'en/mypath') but a different menupath (e.g. 'mypath') the alias cannot be resolved. In this case, the variable $menu contains a menu-item pointing to 'mypath'. Drupal get's into trouble identifying the relation between menu and content, which results in the menu on your page not beeing expanded or activated.
Ok, this is not too complex, but the menu-object also stores data of submenus and page task-bars (i.e. child-menues). These child-menus (they are e.g. the 'show'|'translate'|'edit' task-bars of nodes) are shown on your current page, i.e. their parent-node exists and the path can be de-aliased) are identified in $menu by 'node/XXX/something' while the related menu-item still points to 'mypath'. So drupal get's lost when starting to analyse chield-menues.
What does this mean: The solution proposed by wundo does not generally solve the issue.

I will give it some additional thoughts, but probably go along the approach proposed in http://drupal.org/node/30331#comment-48083
This is from an administration and S/W point of view not too elegant, and you may endup with different menu-trees in different languages, but for the 'enduser' it may be simpler to attach content directly 1-to-1 to a well defined menuelement (especially when he works with menu_otf). ;-)

PS: Hmmm, just a thought for future implementations of i18n and core: How about automatically store a menu-item for each language while hiding this to the user.

I think I found two possible solutions to this problem.

a) code a template_menu_item_link() function in your template that does all the analysis on active menu's, childs and task bars when themeing a menu-item. By this, a lot of analysis is done over and over again and you repeat what is already done in the core. Positive is that you omit drawbacks on other modules. (Hmmm, by the way I was suprised, that the activity of the menu is only identified late in the l() function!)

b) hack the menu.inc file to achieve, that the "missing links" in the menu-data-object are resolved directly after fetching the data from the DB. Doing this, no data is changed in the DB, the missing links are just resolved when the menupathes (e.g. when switching language or administering menues) need update.
After the lines
// Handle URL aliases if entered in menu administration.
$item->path = drupal_get_normal_path($item->path);
in the function _menu_build() insert the following hack:

      // i18n menu hack, bgkaempf 060213
      //   Analyses wether non-linked menu-path matches with language-prefixed
      //   path-alias. If match a is identified, the link is established.
      if (module_exist('i18n') && function_exists('i18n_get_lang')) {
        // check wether menupath-alias is resolvable:
        if (($item->path) == (drupal_get_path_alias($item->path))) {
          // It's not. So check wether alias is found at 'lang_prefix/path':
          $alias_map = drupal_get_path_map();
          if (array_key_exists(i18n_get_lang()."/".($item->path), $alias_map)) {
            //yes, so set menupath to normal path of alias (i.e. de-alias again).
            $item->path = drupal_get_normal_path(i18n_get_lang()."/".$item->path);
            $i18n_orphan_path_found = True;
          }
        }
      }
      // end i18n menu hack

I tested the patch with some modules and different types of pages. I only marginally tested it with e.g. taxonomy. Nevertheless, I hope the patch is quite robust, as it does not touch resolved menupath's or menu's that are hard linked to nodes.

Be aware, that this patch automatically links the menu with path "mypath" to the system path of the alias "current_lang_prefix/mypath" (with current_lang_prefix beeing the current language prefix, e.g. "en") when this alias exists.

Good luck.
bernhard

sorry ... the line $i18n_orphan_path_found = True; is not required and can be deleted. (It's just a leftover from the testing)

mirek,
I used exactly the same i18n download. This is the latest update, as it already includes the i18n menu modul.

When installing i18n: Did you properly install i18n, especially did you patch the corefiles as required by i18n (bootstrap.inc and common.inc)?

bernhard

PS: attached you find the patched core files as required by standard i18n (these are my builds of the standard i18n patches, they are not related the menu-hack I discussed above!).

mirek
sorry for answering late ... I am fighting with some other nodetypes and modules currently ;-).

you write:
6. added the link of this content to the menu (english is node/3 and slovak is node/2 - in the menu is link to the slovak - node/2)

So, when I understand you correctly, you connected the menu with node/2, i.e. you 'hard-linked' the menu-item to the slovak content-item. To make my solution run you would have to:

6.a. give a meaningful alias name to your nodes, e.g. 'welcome':
alias the english node to: en/welcome
alias the slovak node to: ??/welcome (with ?? the 2-letter abbreviation for slovak)
6.b create a menu entry, name it e.g. 'welcome' and point it to the path 'welcome'

My patch then enables the menu to connect to your nodes (en/welcome and ??/welcome) depending on the active language.

Hope this helps.