Этот сайт создан как клуб русификаторщиков. Для нас существуют три основных правила.
1. Мы никому и ничего не должны!
2.Один пришедший на сайт толковый русификаторщик дороже всех пользователей.
3. Мы делаем русификаторы для своего сайта, но в оригинале ими могут пользоваться все в интернете.
Если создать файл RDMAP с жестко-закодированными строками в IDA версии выше 5.5, то Radialix не примет этот файл, сославшись на то, что локализуемый файл проекта был изменён и необходимо создавать новый файл RDMAP. Например, для файла ColorMania.exe я сделал файл RDMAP в IDA v6.8, а затем попытался создать проект перевода. Radiliax выдал такое сообщение:
Хотя, естественно, файл ColorMania.exe не был изменён ни до, ни после создания карты ссылок. В чем же дело? Сделаем файл RDMAP в IDA v5.5 и IDA v6.8, а затем сравним полученные файлы. То, что файлы будут разными - это факт. Но это не значит, что файл RDMAP, сделанный в более старшей версии IDA, будет неверным. Итак,
на представленном рисунке справа файл RDMAP сделанный в IDA v5.5, а слева - в IDA v6.8. Выделенная область на обеих файлах - это контрольная сумма файла, для которого был создан файл RDMAP. Хорошо видно, что она разная (порядок байт обратный), хотя файл ColorMania.exe один и тот же. Так вот, насколько я понял, в новых версиях IDA изменилась функция вычисления контрольной суммы - теперь она определяется по алгоритму CRC. По какому алгоритму находилась контрольная сумма в старых версиях IDA и которую понимает Radialix, я не знаю. Именно на основании этой контрольной суммы Radialix делает вывод о соответствии файла RDMAP локализуемому файлу проекта. Эта проверка сделана не случайно. Если дать файл RDMAP не соответствующей версии или, вообще, от другой программы, то, конечно же, локализованный файл получится неработоспособным.
Лично меня новые версии IDA заинтересовали более шустрым анализом файлов, большей точностью при определении жестко-закодированных строк (не всегда, конечно) и прочими визуальными улучшениями. В отличии от Radialix, программа развивается, но вот из-за смены алгоритма (возможно намеренно) мы не можем ею воспользоваться. Или можем?..
Первый вариант. При помощи НЕХ-редактора в новом файле RDMAP можно ввести контрольную сумму из старого файла, сохранить изменения и подсунуть его Radialix"у. Он его примет, как родного, а полученный локализованный файл программы будет рабочим. Но этот вариант не очень удобен, т.к. нужно держать на ПК две версии IDA, создавать два файла с картой ссылок, и это только для того, чтобы узнать контрольную сумму, принимаемую Radialix"oм.
Другой вариант состоит в блокировке проверки контрольной суммы. Для этого необходимо в исполняемом файле редактора найти место проверки и изменить инструкцию. В этом случае, проверка соответствия файла RDMAP локализуемому файлу проекта возлагается на ваши плечи. То есть необходимо понимать, что если вы случайно изменили исходный файл проекта, например при обновлении на новую версию, то следует также создать для него и новый файл RDMAP, иначе локализованный файл получится "битым".
Есть еще и третий вариант, но в виду его сложности, мы не будем на нём останавливаться.
Leserg, есть одно "НО!" - некоторе время я пользовался версией 6.4, в работе она показала себя просто ужасно, а неторорые программы просто не смогла дизассемблировать(!), в отличие от 5.5, да и как отладчик она некорректно ведет себя, короче,сырая версия. Поэтому я откатился обратно на версию 5.5. Я не знаю кому может понадобиться версия 6.4 под Радиаликс, ведь 5.5 и так вроде нормально строки ищет
Раньше гугл по строке запроса возвращал обработанную строку. Теперь же он возвращает сценарий JAVA, который выполняется на стороне пользователя средствами браузера. Естественно Radialix не заточен для его обработки, поэтому о гуглопереводе в нем можно забыть. Без программного вмешательства в ядро программы уже никто ничего не сделает.
что сервер перевода отдавал, когда еще гуглоперевод работал в Радиаликсе?
возвращал обработанную строку
Что может быть непонятного?
После того, как Google закрыл свои API для перевода, проблема поиска сервисов для машинного перевода стала особенно актуальной. В Интернете много онлайн-сервисов перевода: Promt, Babylon, SDL, Pragma и др. Но, к сожалению, почти все сервисы в ответ на простой GET или POST запрос отдают не результат перевода, а целиком всю страницу, во всей своей красе, начиная с тега DTD. Как говорят у нас на Украине, "дурних нема". На сегодня есть только два сервиса, которые по запросу отдают только результат перевода. Это Bing (от Microsoft) и Yandex (http://translate.yandex.ru/).
Ну с переводчиком Bing пользователи Radialix знакомы и наверняка пользовались его услугами. А вот Яндексом, наверное нет. Правда с ним тоже не все так просто. Согласно его API (http://api.yandex.ru/translate/), по запросу он отдает перевод в формате JSON (JSONP) или XML. Например, для формата JSON отправим запрос на перевод слова "edit"
В этой строке указаны следующие параметры: key - уникальный ключ пользователя (выдается при регистрации); lang - направление перевода (в данном примере с английского на русский en-ru); text - текст, который необходимо перевести (edit).
Конечно же айс, но намного лучше, чем целая HTML-страница. Убрать лишнее в этой строке, думаю, не составит большого труда. Теперь осталось дело за малым - присобачить Яндекс к Radialix'у. Правда там тоже дофига подводных камней: - формат направления перевода другой (Radialix отдает в формате en|ru, а для Яндекса надо en-ru); - последовательность подстановки спецификаторов обратная (Radialix сначала подставляет строку перевода, а потом направление перевода, а для Яндекса надо сначала направление перевода, а потом текст); - может еще какие-то траблы...
Ключ получить не проблема, только длинный он очень (84 символа!), поэтому строку надо будет переносить в другое место.
Вот и получается, а надо ли оно вообще? Было неплохо воскресить программу и привести в чувство автора или на крайняк выцепить исходники и уже работать с ними. Дурень думкою багатіє!
Krig, эммм, меня немного другое интересовало.. ну да ладно, уже нашел что искал.. зы: решение нашел, занимаюсь реализацией..
эко тебя батенька к нам занесло, не уж то проснулся твоя идея с QTranslate конечно хорошая, но сможет ли QTranslate быстро переключаться между строками? в радиаликс это реализовано: отправил - получил, переключился на новую строку опять отправил - получил гугловский скрипт из раиаликса вывдернуть можно, он действительно короткий как и описал Krig, Microsoft_овский горозда длиньше.
и ещё надо учесть, что QTranslate со своими настройками по умолчанию уже конфликтует с некоторыми программами, например в HyperSnap7 не работает захват области экрана, пока включен QTranslate
а может можно какую нибудь dll прикрутить, чтоб была посредником между Radialx и гуглом?
Возможно всё! На невозможное просто требуется больше времени. Мудрец из Шангри Ла
Но на самом деле моя идея выглядит приблизительно так:
Снимаю шляпу... Блин, это же надо, работает! Наверное все гениально просто. LinXP, работает! Не знаю как, но ты это сделал! Спасибо!
на v 2.16 сразу дал ошибку
При запуске, в окошке патча написано:Radialix v3.xx Fixer for TransProx. gazon01, и где ты про версию 2.16 прочитал? Или по привычке все исполняемые файлы скормил патчу? С таким подходом никогда ничё работать не будет.