if i wanna translate the page
it gives the adress like so: http://mysite.com/admin/show/63/admin/admin/show/71/?locale=en_US
but it must be http://mysite.com/admin/show/71/?locale=en_US

how to fix it

This doesn't make much sense, can you elaborate on what you are doing, what version of SS you're using, and what modules you have installed?

Using version 2.3.3
in config

i18n::enable();
global $allowed_i18n;
$allowed_i18n = array('et' => "et_EE", 'en' => "en_GB", 'ru' => "ru_RU");
i18n::set_locale('et_EE');
Object::add_extension('SiteTree', 'Translatable');
Translatable::set_default_locale('et_EE');
Payment::set_site_currency("EEK");
Currency::setCurrencySymbol(' ');

if in estonian link what i have already made i select translate tab and choose language what is en_gb or ru_ru i get the strange adress as shown above

I don't have much experience with the i18n stuff, but that seems to be a likely culprit. Anyone else?

I get the same error, but I'm not using the i18n::enable();

I only have Object::add_extension('SiteTree', 'Translatable');

I have the same error, but only in IE 8 (SS 2.3.7, Translatable enabled)

Strange thing with url, after translated page has been created.
Translated page is created, but redirect to this new page dosen't work correctly.

must be ...admin/show/70, but I have admin/show/50/admin/show/70
where 50 - id of locale page and 70 - id of new, translated page.

Maybe problem in CMSMain.php Link function, row 148?
demo.silverstripe site has the same problem...

Version 2.4 has the same problem, all works fine in Mozilla, Safari, Google Chrome and IE8 in Win7.
This problem occurs only in Windows XP + IE.

Seems, that IE under XP doesn't work correctly with cache. I found this post: http://www.silverstripe.org/general-questions/show/260267#post260267

And I think, that something like this must be added:
if (IE) {clear_all and return blank_URL}

But I cant found, how and were the link generated after translating.
Please help, all ideas are welcome!

It appears that this is a IE specific bug, but it could be alleviated by using a random cache buster string on AJAX request (like all the js/css files carry).

This is part feature, part bug. I think this should go in Trac for the core team to review: http://open.silverstripe.org