Форум: Проблемы искусственного интеллекта

Регистрация | Вход

Все темы | Новая тема  Стр.4 (6) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: автоматический перевод текстов.
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 17 апр 07 0:25 Цитата: Вообще, многие считают машинный перевод чем-то сильно сложным. Однако уже существующие идеи - достаточно просты. Что же касается фильтра и системы анализа текста - тут мы просто рассчитываем вероятность появления того или иного слова (или его отсутствие) в предложении и ничего больше. Если вероятность велика, а его нет, или присутствует соовсем другое слово, вероятность появления которого крайне мала, то мы помечаем перевод как _возможно_ неправильный и/или некорректный/неточный. Ничего сверхъестественного.. Что то, мне кажется, вы сильно утрируете... давайте с примерчиком попробуем? вот возьмите любой абзац и расскажите, как вы будете проверять его перевод! Кроме того, я не сказал, что это не выполнимо. Я просто сказал, что это сложно, и делать вспомогательный инструмент по сложности, почти как проект... не знаю, не знаю... [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 17 апр 07 1:39 > Что касается разбиения на различные предложения, ... такое разбиение сложно сделать, а если учитывать, что в разных языках, разные правила построения и препинания, вообще почти не реально (единым способом). Нет, это как раз реально. Я еще в начальных постах этой темы говорил, что один мой коллега написал прогу, которая парсила текст на любом языке и даже разбивала его на слова, а потом группировала эти слова в логические группы. Но нам-то надо сделать нечно значительно более простое. Просто найти способы разбиения сложносоставного предложения на части. Все дело в полноте БЗ. > Ну совершенно с этим не согласен. Это не рационально и не удобно. Почему? Нам не будет неудобно, не будет и нерационально. Просто больше машинного времени. Зато с базой можно будет работать как любым субсистемам, так и людям. + я же предлагаю еще и 3-й тип базы - специализированная под каждую субсистему. Таким образом, каждая новая субсистема может пробежаться по всей asis базе и создать свою базу внутреннего представления информации и уже в последствии с ней и работать и в нее же заносить все изменения. Да и парсить-то не придется.. все можно сделать значительно проще, например проиндексировать всю базу один раз, а потом там будет на каждое слово определенный набор предложений. Да много каких способов работы с информацией существует.. однако это все уже premature optimization, что считается плохой техникой программирования. Если будет медленно работать, там уже определим, что оптимизировать. А пока надо сделать как проще. > Та структура БЗ, которую я предложил, с лихвой покрывает ваш пример Она не покрывает уже хотя бы потому, что надо разбивать все на слова.. А это не есть хорошо. К тому же у каждого слова есть разные значения. Это придется как-то хэндлить. + в латинских языках существует управление словом, а в русском - падежи и склонения (что существует в китайском - даже не знаю). И при разбитии на слова это все придется как-то обрабатывать. Это ненужные дополнительные сложности. Смысл-то в том, чтобы как раз все было предельно просто. Простота же была первоначальной идеей! > Что то, мне кажется, вы сильно утрируете... давайте с примерчиком попробуем? Ну давайте попробуем! Запостите пару абзацев текста из классической литературы + пример базы знаний и я продемонстрирую, как будет работать проверка перевода. > Кроме того, я не сказал, что это не выполнимо А я не сказал, что будет очень легко.. Просто он будет сильно в помощь.. Как без него обойтись? Это фактически - обязательная часть проекта.. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 17 апр 07 4:51 Цитата: >Я еще в начальных постах этой темы говорил, что один мой коллега написал прогу Причем тут то, что написал ваш коллега? это, знаете ли, английский легко на мелкие предложения разбивать, а попробуйте простые правила для русского придумать? Вы наверное забыли, что в нем обороты по форме слова определяются? Цитата: >Просто больше машинного времени. Во-первых, не просто больше, а намного больше. Во-вторых, давайте вообще без DB работать. Ну а что, каждый метод будет сам себе базу составлять (а можно и прямо online). Для чего нужно разбивать на мелкие предложения? Это далеко не для каждого метода нужно!! И это совсем не premature optimization. Это uniform data representation. Uniform по отношению к различным методам перевода. Цитата: >например проиндексировать всю базу один раз, а потом там будет на каждое >слово определенный набор предложений. А я что по вашему предложил? Цитата: >Она не покрывает уже хотя бы потому, что надо разбивать все на слова. И чем это плохо... ну скажем, для метода сравнения предложений. Тем что упростит сравнение? Тем что его можно будет сделать через db arithmetics? Цитата: >в латинских языках существует управление словом, а в русском - падежи и склонения Это я и называю формой слова (например). Есть и другие способы нормализации слова, не связанные с классической лингвистикой, но широко применяемые в IR. Цитата: >Это ненужные дополнительные сложности. Сложности появятся, когда вся информация одной сплошной кучей. и при каждом маломальском сравнении нужно заново эту кучу разбирать. Как вы думаете, для чего вообще db придумали? Цитата: >Зато с базой можно будет работать как любым субсистемам, так и людям. субсистемам проще работать с правильно организованной базой, а для людей, можно хранить ссылки (doc_ID, start_location, end_location) для каждого предложения на источники, из которых при желании легко получить первоначальную форму и даже весь контекст вокруг. простота - это не значит халтура [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 17 апр 07 18:22 > это, знаете ли, английский легко на мелкие предложения разбивать В том то и дело, что не английский прога парсила, а именно русский, румынский и подобные языки.. и что самое интересное, очень грамотно сгруппировала слова. Я сильно в суть не вникал, но результаты даже несколько удивляют. Так что вот.. >> Просто больше машинного времени. > не просто больше, а намного больше. Это не столь важно. Сейчас машинное время очень дешево. У меня есть почти неограниченные машинные ресурсы. Так что, за этим дело не встанет. > давайте вообще без DB работать Зачем? DB - это хоть обычные .txt файлы.. не важно как хранится информация, любое хранилище информации является DB, так что в нашем случае без DB не обойтись по определению. Это относится и к вашей фразе "Как вы думаете, для чего вообще db придумали?". База данных - это хранилище информации. Если Вы подразумеваете под DB - DB Engine, то это уже другой вопрос. Я сложу всю базу знаний в обычный текстовый файл - это уже будет DB. Посему мне не понятно, о чем идет речь. И еще раз: я же резервирую 3й тип репрезентации БЗ специально под каждую подсистему, чтобы та хранила там свою информацию согласно своей реализации и своим нужнам, которые у каждого метода будут свои. Например, для моего метода не нужно то представление БЗ, что Вы предложили. А имея всю базу знаний в оригинальном виде мы даем новым подсистемам возможность проинициализировать один раз в начале свою базу нужными значениями и в дальнейшем с ней и работать. > Для чего нужно разбивать на мелкие предложения? Это далеко не для каждого метода нужно Я согласен. Поэтому и предлагаю держать 3 типа базы знаний: 1. из источников 2. для пользователей 3. под каждую подсистему Я не вижу принципиальных проблем с таким разделением. Первые 2 нужны в любом случае. Я не уверен, что можно восстановить из вашего формата БЗ оригинальные фразы/предложения. Да и еще раз: ваш метод подразумевает разбиение на слова и еще к тому же выделение корня/унитарной части, что уже само по себе сложно и не даст возможности восстановить фразу (или же информации потребуется хранить еще больше, чем если в "сыром" виде). >> Она не покрывает уже хотя бы потому, что надо разбивать все на слова. > И чем это плохо? Я не говорил, что это плохо, я говорю, что это сложно! Вы наперед знаете, как разбить на слова китайский текст? А прога должна работать с любым языком без спец. заточки под конкретный язык. > Сложности появятся, когда вся информация одной сплошной кучей. и при каждом маломальском сравнении нужно заново эту кучу разбирать. Не согласен. Вы сейчас говорите об оптимизациях. А это не так важно на данном этапе. Если у нас будет 1 мег текстов, его обычный комп обработает за доли секунды (а у меня есть большое количество hi-end серверов, каждый в сотни раз мощнее обычного P4 3GHz). А на первых порах больше пары мегов теста у нас и не будет! Так что предлагаю сосредоточить внимание на более принципиальных моментах реализации. Например, над алгоритмом перевода. Давайте лучше о нем поговорим? P.S. > простота - это не значит халтура Вы ж не хотите сказать, что я халтуру предлагаю? [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 17 апр 07 20:41 Цитата: > это, знаете ли, английский легко на мелкие предложения разбивать В том то и дело, что не английский прога парсила, а именно русский, румынский и подобные языки.. и что самое интересное, очень грамотно сгруппировала слова. Я сильно в суть не вникал, но результаты даже несколько удивляют. Так что вот.. А я не про программу вашего коллеги говорил. Он что, тоже на мелкие предложения разбивал в рамках своего алгоритма? Цитата: > Для чего нужно разбивать на мелкие предложения? Это далеко не для каждого метода нужно Я согласен. Поэтому и предлагаю держать 3 типа базы знаний: 1. из источников 2. для пользователей 3. под каждую подсистему Значит, мы о разном говорили. Я имел в виду 2 уровня строения из вашего пункта "3". Но в таком случае, совсем не вижу причину, специально создавать БД пункта "2". Как она будет влиять на остальные уровни? вообще, как по вашему эти уровни связанны между собой? Таким образом, следуя вашему делению, считаю, что должно быть 2 уровня. 1. источники 2. DB Engine (именно его я имею в виду когда говорю DB, т.е. структурированные и упорядоченные данные). А уже в рамках 2-ого : разделение на различные системы перевода и human интерфейс. Причем, изменения последнего должны менять остальные базы, иначе на-фига это нужно? Цитата: Я не уверен, что можно восстановить из вашего формата БЗ оригинальные фразы/предложения. Ну возможно не один к одному, но это и не надо. оригинал можно и в источниках взять. Я говорю об удобном для работы формате. Цитата: Да и еще раз: ваш метод подразумевает разбиение на слова и еще к тому же выделение корня/унитарной части, что уже само по себе сложно и не даст возможности восстановить фразу (или же информации потребуется хранить еще больше, чем если в "сыром" виде). Во-первых, не все нормализации сложные (конечно, выделение корня не тривиально, но это далеко не единственный способ). Во-вторых, я и не говорил, что хранить надо будет меньше информации. Я говорил, что работать с ней будет удобнее. Цитата: Вы наперед знаете, как разбить на слова китайский текст? Вот только давайте не будем про китайский текст. Я лично даже приблизительно не знаю как их язык устроен, и возможно, то что просто в других языках, совершенно не подходит для дальневосточных языков. Вы еще языки индейцев вспомните. Лично меня в первую очередь, интересует рус-анг-рус, а если это будет работать на других языках автоматически - Замечательно, с маленькими доработками - Неплохо, вообще не будет работать - Ну и черт с ним. Цитата: > простота - это не значит халтура Вы ж не хотите сказать, что я халтуру предлагаю? Да боже упоси... Цитата: Например, над алгоритмом перевода. Давайте лучше о нем поговорим? Ну давайте поговорим о нем. Все равно, к структуре DB в конце придём. Это не принципиально. И так, на данный момент было 2 основных направления : 1 - Выделение по сходству(LE). В нем основная идея, сравнивать предложения, находить наиболее похожие и из них складывать перевод. 2 - Статистический перевод(ST). В нем слава/фразы, переводятся дословно, но форма подбирается в соответствии с соседними словами на основе наибольшей вероятности. Кроме этого, нужно придумать, как же соединять/отбирать разные варианты перевода с разных систем(TC). [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 17 апр 07 23:43 > А я не про программу вашего коллеги говорил. Он что, тоже на мелкие предложения разбивал в рамках своего алгоритма? Он, как раз, работал с токенами (словами/частицами). Т.е. он различал все, что разделялось пробелами и другими знаками препинания. > ... совсем не вижу причину, специально создавать БД пункта "2". Как она будет влиять на остальные уровни? вообще, как по вашему эти уровни связанны между собой? Разница между первым и вторым типом в том, что п2 будет несколько оптимизирована для удобности восприятия человеком. Но, как я уже говорил в предыдущих постах - эти 2 типа будут достаточно похожи и, возможно, второй тип можно генерировать on-the-fly. А связаны они между собой особо никак. Т.е. они существуют параллельно друг другу. Если вносится изменение в БЗ первого формата, она так же заносится во все остальные форматы БЗ. Можно согласиться и с вашим делением на 2 уровня. По мне - на данном этапе это не так принципиально. Если берем 2 типа, надо определить тогда, как в каждом из них будет все храниться. Или, пока только для первого типа. Вот если взять первый тип как "источники", как в нем хранить источники и как это представлять пользователю? Хранить 1-to-1 или 1-to-n? Или может быть n-to-n? И как потом это представлять пользователю? Я имею в виду: многие фразы, очень похожие, где разница заключается, например, в цвете ("я увидел красный дом", "я увидел синий дом") - нет смысла выдавать пользователю как разные. Их надо как-то сгруппировать или еще что-то. > Ну возможно не один к одному, но это и не надо. оригинал можно и в источниках взять Вот именно для этого я и хочу хранить источники в неизмененном виде. > Вот только давайте не будем про китайский текст Идея моего подхода как раз тем и хороша, что должна работать с любым неизвестным мне языком, хоть с инопланетным. Была бы база знаний под него.. То, что предлагаете Вы - это как раз стандартный подход к машинному переводу. Т.е. разобраться с лексикой, синтаксисом, семантикой и, возможно, с програмичностью для конкретно взятого языка. Суть же моего подхода заключается в том, чтобы переводить не имея каких-либо знаний о языке по этим вопросам. Можно идти и вашим подходом, но он значительно более сложный. И, в общем-то, уже существует много чего в этом направлении (например, translate.ru), особо выдающихся результатов не показавшее. Насчет алгоритма: мне не совсем понятно насчет приведенных Вами 2х направлений и их описаний. Насколько я понимаю, все, о чем тут идет речь, есть Statistical machine translation (http://en.wikipedia.org/wiki/Machine_translation). Но это НЕ есть "В нем слава/фразы, переводятся дословно, но форма подбирается в соответствии с соседними словами на основе наибольшей вероятности". То, что Вы описали есть Transformer Approach. А что такое "Выделение по сходству" я так и не понял. Не могли бы Вы привести ссылки на описание этих 2х направлений? Кстати, возможно будет инетресно почитать про гугловый переводчик: http://en.wikipedia.org/wiki/Google_Translate > Кроме этого, нужно придумать, как же соединять/отбирать разные варианты перевода с разных систем(TC). Я об этом тоже задумывался, пока кроме статистического соединения и полностью раздельного перевода в голову ничего не пришло. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 18 апр 07 1:38 Цитата: > А я не про программу вашего коллеги говорил. Он что, тоже на мелкие предложения разбивал в рамках своего алгоритма? Он, как раз, работал с токенами (словами/частицами). Т.е. он различал все, что разделялось пробелами и другими знаками препинания. Ну я так и думал....вот только вы постоянно приводите его работу как иллюстрацию к тезису о простоте разбиения сложных предложений на более мелкие. Или я не правильно понял? Цитата: А связаны они между собой особо никак. Т.е. они существуют параллельно друг другу. Если вносится изменение в БЗ первого формата, она так же заносится во все остальные форматы БЗ. Что то я это не до конца понимаю. Источники это источники. Т.е. представьте огромный текст на анг. и такой же огромный текст на рус. Вот это и есть источник (ну только реально, таких пар документов будет много) Цитата: Можно согласиться и с вашим делением на 2 уровня. По мне - на данном этапе это не так принципиально. Если берем 2 типа, надо определить тогда, как в каждом из них будет все храниться. Или, пока только для первого типа. Что то я не понял. Вы же сами предлагали это не продумывать?! Мол как получили, так и будем хранить, и парсить прямо online или оffline но это проблемы каждого метода отдельно. Цитата: Вот если взять первый тип как "источники", как в нем хранить источники и как это представлять пользователю? Хранить 1-to-1 или 1-to-n? Или может быть n-to-n? И как потом это представлять пользователю? Я имею в виду: многие фразы, очень похожие, где разница заключается, например, в цвете ("я увидел красный дом", "я увидел синий дом") - нет смысла выдавать пользователю как разные. Их надо как-то сгруппировать или еще что-то. Цитата: Вот именно для этого я и хочу хранить источники в неизмененном виде. Что то у меня подозрение, что мы понятия "источники" по разному понимаем. для меня это сборник пар документов. в каждой паре рус. и анг. версия. Цитата: То, что предлагаете Вы - это как раз стандартный подход к машинному переводу. Т.е. разобраться с лексикой, синтаксисом, семантикой и, возможно, с програмичностью для конкретно взятого языка. Суть же моего подхода заключается в том, чтобы переводить не имея каких-либо знаний о языке по этим вопросам. В каком месте, я предлагал разбираться с лексикой, синтаксисом и семантикой? Все что я хотел сделать, это пропарсить токены (т.е. выделить слова и нормализовать их например Porter Stimmer-ом). Кроме это, я и не говорил, что придумал, что то супер новое. Просто статистические методы, не используют никакой информации кроме статистической (ну как раз то что вы и хотите). Цитата: Можно идти и вашим подходом, но он значительно более сложный. И, в общем-то, уже существует много чего в этом направлении (например, translate.ru), особо выдающихся результатов не показавшее. Во-первых результаты в платной версии у них не плохие (ну уж точно не хуже Google-я). Во-вторых, с чего вы взяли, что ни стат. методы используют? Я не думаю, что этот способ сложнее чем тот, что вы хотите предложить. Цитата: Насчет алгоритма: мне не совсем понятно насчет приведенных Вами 2х направлений и их описаний. Насколько я понимаю, все, о чем тут идет речь, есть Statistical machine translation (http://en.wikipedia.org/wiki/Machine_translation). Но это НЕ есть "В нем слава/фразы, переводятся дословно, но форма подбирается в соответствии с соседними словами на основе наибольшей вероятности". То, что Вы описали есть Transformer Approach. Вы имели в виду Transformer Approach = Dictionary-based machine translation? Но это не так. Я же сказал, что форма слова зависит от соседний и подбирается статистически. Т.е. смотрится "окно" из нескольких слов и на основе стат. данных делается перевод центрального слова. Цитата: А что такое "Выделение по сходству" я так и не понял. Не могли бы Вы привести ссылки на описание этих 2х направлений? Нет не могу. это не где то прочитанные способы. кроме того, первый вы сами же предложили. вы же сами писали, что гоогле примерно так переводит. Цитата: > Кроме этого, нужно придумать, как же соединять/отбирать разные варианты перевода с разных систем(TC). Я об этом тоже задумывался, пока кроме статистического соединения и полностью раздельного перевода в голову ничего не пришло. Что значит "статистического соединения" и "полностью раздельного перевода"? т.е. есть источник : [A B C D]. и есть к нему два перевода : [1 2 3 4] [1 4 6 2] что с ними делать? [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 18 апр 07 18:12 > вот только вы постоянно приводите его работу как иллюстрацию к тезису о простоте разбиения сложных предложений на более мелкие. Или я не правильно понял Нет, я не привожу его работу как пример простоты разбиения на простые предложения. Простые предложения разбиваются иначе, чем в той программе - по тому же самому принципу, как осуществляется перевод в моем способе перевода. > Т.е. представьте огромный текст на анг. и такой же огромный текст на рус. Вот это и есть источник Не совсем.. Я предлагаю хранить не текст-to-тест, а предложение-to-предложение (или может быть n_предложений-to-n_предложений, где n_предложений имеется в виду n очень похожих/почти одинаковых по смыслу предложений). Т.е. текста как такового уже не будет. Будут предложения из него. Сейчас я хотел бы определиться с тем, стоит ли хранить предложения 1-to-1, или можно хранить и many-to-many? Так же остается открытым вопрос о том, оставлять ли старый вариант перевода, если предложен более точный новый? Или может быть оставлять, но в архивном подразделе БЗ? Т.е. в том, что будет существовать для возможности восстановления любой информации, но при переводах использоваться не будет. > Вы же сами предлагали это не продумывать?! Это я предлагал для 3го типа (который для каждой подсистемы), а первые 2 (или первый один с двумя подпунктами) надо определить, т.к. от этого будет зависить интерфейс вики. Хотя и это, как я уже вижу сейчас, не так важно, т.к. этот интерфейс будет нужен пользователям только после того, как начнет работать программа. Т.е. пока стоит определить только как хранить источники (т.е. первый тип ("1. из источников")), т.к. он потребуется на самом первом этапе при обработке текстов. > Что то у меня подозрение, что мы понятия "источники" по разному понимаем. для меня это сборник пар документов. в каждой паре рус. и анг. версия. Действительно, наверное по-разному.. Я под источниками понимаю не текст целиком, а предложения/фразы из текста соотнесенные с соответсвующими предложениями на другом языке. Причем я на данном этапе еще даже не знаю, стоит ли хранить сложносоставные предложения целиком, или же разбивать их и хранить как простые. Дело все в том, что в переводе может как раз получиться, что сложное предложение на одном языке переведено очень точно на другой язык, но в 2х предложениях. Как тогда их соотносить, если не разбивать? Над этим вопросом еще стоит подумать. Видится мне, нужно хранить именно простые предложения, либо же непосредственно фразы. Еще тут есть такой нюанс, что при хранении по предложениям нужно все же будет так же хранить информацию о том, какие предложения шли друг за другом, дабы потом иметь возможность различать контекст. Можно, конечно, хранить еще и целиком тексты на всякий случай. Но в любом случае на определенном этапе придется разбивать текст на предложения и определять соответствие предложения на одном языке такому же предложению на другом языке. > выделить слова и нормализовать их например Porter Stimmer-ом Выделение корня методами типа Porter Stemmer относительно легко только в английском. Уже в русском заставить его хорошо работать значительно сложнее, не говоря уж об арабском, и тем более китайском/японском. http://en.wikipedia.org/wiki/Stemming#Language_Challenges Тот медот, что предлагаю я, должен хорошо работать даже по направлению ru-hex_en-ru, т.е. с русского на хексовое представление текста на аглийском (коды символов), где даже не будет возможности изначально выделить пробелы и знаки препинания. Т.е. перевод при нулевом знании о языке. Насчет алгоритма: мы тут похоже друг друга сильно запутали, т.к. думали, что говорим об одном и том же, а получилось как раз наоборот. Хоть наши подходы в чем-то имеют определенное сходство (статистическое нахождение правильного варианта), но суть их достаточно различна. Поэтому я предлагаю нам выполнить каждому свое направление алгоритма, а потом их совместить. Т.е. 2 разных алгоритма перевода на одной и той же базе знаний в одной и той же системе с одним и тем же интерфейсом. А теперь как раз для совмещения под одной крышей 2х алгоритмов: > Что значит "статистического соединения" и "полностью раздельного перевода"? Второй метод - это прямо предложить пользователю 2 варианта перевода по-отдельности. Т.е.: "алгоритм А перевел ваше предложение так то; алгоритм В перевел ваше предложение так то". А первый - это попытаться совместить оба перевода. Например, если один алгоритм при переводе столкнулся с неоднозначностью перевода и для него перевести с одним словом (первый вариант) так же правильно, что и с другим (второй вариант), при этом первый алгоритм изначально выбрал первый вариант, а другой алгоритм при этом использует при переводе второй вариант, то в этом случае первый алгоритм может "согласитсья" на второй вариант, т.к. для него они одинаково правильны. Если формализировать такой подход, то можно описать его так: выдавать тот перевод, вероятность правильности которого выше. Например, в вашем примере [1 2 3 4] и [1 4 6 2], если вероятности (в процентах справа от -> ) таковы, что [1->90 2->30 3->70 4->15] и [1->50 4->70 6->50 2->40], то релультирующий перевод будет [1 4 3 2]. При этом цифры 1 2 3 4 6 и 2 - это не обязательно слова. Согласовать можно и их порядок, и другие моменты. Сразу замечу - это лишь предварительная мысль, которая напрямую может и не работать. Но если продумать ее имплементацию, думаю, она может дать неплохие результаты. В целом, если оба алгоритма будут хорошо работать, то нестыковки у них будут возникать лишь по сомнительным местам перевода. А там можно будет согласовать их статистически. Вряд ли одно и то же предложение будет иметь два и более принципиально нестыкуемых _правильных_ перевода. [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 03 май 07 3:03 daner, на sf.net уже зааппрувили project takeover и opentrans сейчас является нашим проектом! вот ссылка: http://sourceforge.net/projects/opentrans и http://opentrans.sourceforge.net (это типа начальная страница вебсайта проекта, пока там ничего нет) Так что, можно приступать к написанию кода.. Пошлите мне сообщение черес sf (http://sourceforge.net/sendmessage.php?touser=1769019) и я добавлю Вас в список админов проекта (для этого Вам надо иметь учетную запись на сф). Все остальные желающие участвовать в разработке системы, милости просим.. Заходим на http://sourceforge.net/project/memberlist.php?group_id=195115, выбираем разработчика, выделенного жирным (пока я там только один) и посылаем ему сообщение. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 03 май 07 5:18 Послал. мой user : danerde. правда, пользоваться я этим сайтом не умею . Как то не приходилось open source писать (т.е. в команде не приходилось). так что требуется некоторый лекбез [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 03 май 07 6:54 Готово, user danerde занесен в список админов с максимальными правами. Принцип там таков: Написание кода происходит следующим образом: новый файл пишется локально (на своем компе), далее он заносится в CVS репозиторий (для взаимодействия с репозиторием существует много программ, хорошо себя зарекомендовал плагин для eclipse) и все остальные получают к нему доступ либо только на чтение, либо и на изменение (в зависимости от выставленных прав). Если есть права на изменение (а это есть у всех разработчиков проекта), то можно сделать check-out, т.е. достать файл из репозитория для изменения, изменить его и сделать check-in, т.е. занести новую версию файла в репозиторий. Репозиторий в свою очередь ведет учет всех версий файлов и, при желании, можно вытащить любую модификацию файла, указав его ид. Далее, в репозитории по умолчанию есть одна ветка - main. В ней обычно находится основная версия программы. Можно создавать дополнительные ветки (например, как в линуксе - stable и unstable), но с этим надо осторожно (в смысле не создавать 20 веток), т.к. изменения придется вносить вручную во все эти ветки, либо же как-то хитро их настраивать, чтобы изменения в одной автоматически происходили бы и с другой. В общем, обычно, больше 2-3 веток (включая main) не используют. На СФ есть сервера для теста программ. Причем, доступны практически все используемые в индустрии платформы (от виндоус до unicos/mp). Таким образом, сначала мы пишем код, потом его заливаем в репозиторий, далее другие участники и мы сами меняем код, потом компилируем средствами СФ, тестим на их системе и релизим код и, если нужно, executables. Релизить означает объявить такую-то версию протестированной и стабильной. Далее, различаются несколько стадий проекта: 1. Planning, т.е. планирование и определение хода разработки. Мы сейчас в нем. 2. Pre-alpha, т.е. состояние, когда уже есть код, почти готовый для компиляции и выпуска alpha версии 3. Alpha, т.е. самый первый executable, который прошел unit-test (т.е. тест программистов). на этой версии никто из юзеров программу не использовал. 4. Beta, т.е. когда уже программа более или менее стабильно работает, прошла system tests (тесты тестеров) и ее успешно использовали end-users (конечные пользователи, для которых программа и предназначается) 5. Release, т.е. когда система уже прошла серьезные испытания в народе и была признана работоспособной. Все версии до release должны нумероваться, начиная с 0 (v0.1, v0.2.1, и т.п.). Первая release версия получает номер v1.0 (v1.0.0). Незначительные изменения должны нумероваться второй и третьей цифрой (v1.x.y). Очень значительные изменения (раз в год) приводят к инкременту первой цифры и обнулению всех остальных (v1.8 -> v2.0). Это что касалось кода. Дальше, в системе можно репортить и track'ить баги, выкладывать документацию (ею тоже можно управлять через репозиторий), создавать мэил-листы и осуществлять рассылки подписчикам, управлять форумом проекта, создавать задачи для выполнения их участниками (типа todo списка - исправить баг #18; протестить release-кандидат v2.3.2; написать документацию на функцию Х и т.п.), рекрутировать разработчиков, тестеров и другой полезный народ и даже собирать пожертвования. Ну вот, думаю, как ликбез выше написанное подойдет. [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 03 май 07 7:16 Сейчас у меня есть один насущный вопрос - где и на каком языке вести обсуждения по проекту и выкладывать документацию? SF, преимущественно, только English-friendly. Т.е. будет несколько странно для всех посетителей СФ увидеть в форуме проекта текст на русском. С другой стороны, пока что все разработчики, да и вообще, все кто знает о проекте - русскоязычные. Поэтому, я думаю, можно сделать так: то, что может заинтересовать участников форума GotAI, писать в этой теме на русском, а все остальное - в форуме проекта на английском. Кстати, он тут: http://sourceforge.net/forum/?group_id=195115. Другой вариант - вести дублирование всей информации на обоих языках. Но, на мой взгляд, это уже будет несколько обременительно. Еще вариант - вести форум проекта преимущественно на английском, а некоторые, отдельные темы (как исключение) – на русском. [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 03 май 07 8:50 Так, немного стартанул проект на СФ: добавил задания (это я project manager'ом заделался ): http://sourceforge.net/pm/?group_id=195115 и открыл 2 темы для обсуждения алгоритмов/подходов реализации и формата базы знаний: http://sourceforge.net/forum/forum.php?forum_id=691076 Так что, база для старта уже есть.. [дополнение от 07.05.03 6:50GMT]: залил простенькую начальную страницу: http://opentrans.sourceforge.net [Ответ][Цитата]
гость 82.179.191.*	На: автоматический перевод текстов. Добавлено: 05 май 07 5:12 Так всё уже сделано : http://code.google.com/p/pravda/ C удовольствием отвечу на все Ваши вопросы. C уважением, ignat [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 05 май 07 5:45 Зашел на сайт проекта prawda, ознакомился. Заключение: нет, не совсем все уже сделано (это даже не имея в виду, что prawda находится на alpha-стадии). Да и идеи у проектов почти совсем разные. Наша с daner’ом идея заключается, во-первых, в том, чтобы сделать переводчик с открытым кодом и открытой базой, которая будет одна на весь мир, база – по принципу wikipedia. Т.е. каждый может заносить свои переводы и подправлять уже существующие, при этом всё будет лежать в одном месте. А во-вторых, prawda особо ничем не отличается от обычных переводчиков, вроде translate.ru. Суть же нашего проекта в том, чтобы переводчик сам, без помощи человека, основываясь на статистических данных, мог правильно, с учетом контекста, выполнять переводы. У нас другой принцип нахождения перевода. Основывается он на том, что системе сначала скармливается текст, переведенный на оба языка, после чего система сама учится переводить с одного из языков на другой и обратно. Причем, в моем видении проекта, система должна мочь переводить с любого языка на любой, без специальной заточки под каждый из них (ни морфологических, ни синтаксических, ни каких-либо других знаний о языке не требуется, т.е. нулевое знание языка). Я думаю, Вам будет лучше понятна идея, если вы прочитаете всю тему целиком. [Ответ][Цитата]
Стр.4 (6): 1  2  3  [4]  5  6 << < Пред. | След. > >>