Собственно идея не нова
Я уже несколько раз про свой проект писал на RSDN, но все-таки — вдруг кто заинтересуется?
Для тех, кто читал ранние посты — забудьте о том
как там все было реализовано
Проект является попыткой написать легко модифицируемую/расширяемую систему обработки текста, для получения его перевода (в принципе — начиналось все с переводчика, но всегда можно попробовать найти не традиционный способ ичпользования традиционных вещей
)
Как переводчик, предоставляет следующие основные возможности
— многовариантный перевод слов
— многовариантный перевод отдельных предложений
— единое представление единиц "слово" и "предложение" во всех частях алгоритма перевода
Моя идея в следующем:
— все элементы алгоритма перевода представляются в виде интерфейсов
— все интерфейсы загружаются динамически, таким образом, реализацию
любой части алгоритма можно легко заменить на другую — более удобную (естественно, при этом от удаляемой реализации не должны зависеть другие части алгоритма (именно на
реализацию, а не на ее интерфейс), думаю понятно почему
)
Структурная схема алгоритма тут:
http://img169.imagevenue.com/img.php?image=55125_classdiagram1_122_578lo.jpg
Комментарии по схеме (за названия классов/интерфейсов просьба сильно не бить
):
IGUIModule — интерфейс для плагинов к GUI — например, для того чтобы, например, в меню основной программы можно было легко встроить вызов специфического редактора бд или еще чего-нибудь (в том числе и какой-нибудь дополнительной функциональности)
TTextParser — реализация описания обратываемого текста. Базируется на интерфейсе
ITextParser — для того, чтобы мою реализацию GUI можно было смело выкинуть, если что
ISentence — описание одного предложения вместе со всеми его вариантами перевода
IParagraph — описание параграфа, состоящего из предложений. Соответсвенно — ITextParser состоит из списка параграфов.
ITextPos — текущее выбранное слово в тексте и его позиция в описании текста
ITextGenerator — занимается преобразованием из описания текста к тексту. Попросту говоря — генерирует текст перевода и оригинала (если вдруг и это надо)
ILexer — алгоритм лексического анализа, выполняет преобразование из текста к списку слов TMWord
TMWord — класс, содержащий в себе всю необходимую информацию о слове, как то:
— исходная форма
— начальная форма (то, как это слово выглядело до склонения)
— список параметров слова (род, число и т.п.)
— список частей речи слова — зависит от того, какие есть у слова переводы и от их частей речи
— дополнительные параметры, пока не важно, я думаю
TEStr — класс, описывающий исходное предложение. Содержит все необходимые функции для удаления, добавления слов, управления связями междлу словами. Также — умеет производить свертку последовательности слов, что позволяет представлять, например, словосочетания как одно слово (моя реализация алгоритма анализа этим активно пользуется)
TRStr — фактически — список слов из TEStr с их переводами. Его наличие позволяет упростить генерацию выходных текстов. Но об этом — потом
Самим процессом перевода управляет класс
TTextTranslator.
Перевод осуществляется построчно. Процесс перевода выглядит так:
— Определяются все исходные формы слов в предложении и получаются их варианты перевода. За это отвечает
IWordTranslator
— Последовательно вызываются все зарегистрированные в системе
IEStrProccessor. При помощи них можно производить, например, поиск фраз, анализ — вообщем любую обработку текста
— Вызывается IStrVariantsGenerator, который генерирует несколько вариантов "перевода" предложения. То есть те предложения, которые необходимо обрабатывать дальше, чтобы отбросить некорректные/неправильные. В моей реализации генерация производится по принципу: каждое слово в предложении имеет переводы только одной части речи.
— Последовательно вызываются все зарегистрированные в системе
IEStrProccessor2. Которые также производят анализ, но уже сгенерированных на предыдущем этапе вариантов перевода.
— Производится преобразование переводов предложения в формат TRStr и последовательно вызываются все зарегистрированные в системе
IRStrProccessor. На этом этапе, например, можно производить склонение/спряжение слов
По окончании обработки всех предложений генерируется выходной текст.
Примечание: на рисунке отдельно выделены блоки IWordTranslator и IDeclenser (интерфейс модуля для склонения слов). Причина — проект активно рефакторится. По идее — эти два блока должны относиться к IEStrProccessor и IRStrProccessor соответственно. Я над эти работаю
В идеале — TextTranslator также должен быть выполнен в виде динамически подгружаемого модуля.
Хотелось бы узнать мнение специалистов ну и вообще — покритикуйте
Может быть что-то поправлю пока еще не поздно.
Ну и вообще — вдруг кто заинтересуется и присоединится
Или же прикрутит свой алгоритм к моему
P.S.: то что вы видите — работающий проект. 18 версия
Даже переводит. Не то чтобы хорошо — но и не так чтобы совсем уж плохо. Но пока что упор я делаю именно на программную часть, правила перевода — дело наживное
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Здравствуйте, <Аноним>, Вы писали:
А>по-простому: а где брать словари?
Ручками набивать
На самом деле словарь — это только маленькая часть переводчика. Там кроме пар англ.слово->перевод еще куча дополнительной информации нужно (параметры слов: род, например + склонение/спряжение для слов). Но все это
в моей реализации алгоритма. Алгоритм сделан так, что любой его кусок можно заменить какую-либо иную реализацию. Соответственно, если у кто-то занимается, например, исследованием текстов — то процесс разработки программы можно сильно сократить, т.к. все что нужно уже есть, а чего нет — можно прикрутить самостоятельно
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Здравствуйте, <Аноним>, Вы писали:
А>а ты с переводчиками общался? Для них главное не алгоритм а перевод.
Конечная цель не в этом. Разрабатываемая система является
базой для того, чтобы те самые переводчики могли проверить свои предположения, алгоритмы, и вообще — что угодно
Представь что тебе пришла в голову идея как улучшить результат перевода.
1. Берем ПРОМТ... Плюем и выбрасываем — нет практически никакой возможности как-то повлиять на результат. То что есть — ну этого мало.
2. решаем писать свое — ну хотя бы чтобы посмотреть, а вдруг то что мы придумали работает?
Итак, надо написать:
1. Словарь (научиться работать с чужим или написать полностью свой)
— ну, естественно, интерфейс для ввода данных в словарь
2. Жизненно-необходимые алгоритмы:
а) лексический анализ
б) морфологический анализ
в) поиск фраз
г) синтаксический анализ
д) алгоритм склонения/спряжения слов
3. Ну, естественно — интерфейс для взаимодействия с пользователем. Хотя бы чтобы текст можно было ввести и получить результат
Это по-минимуму. Каждая из этих задач достаточно сложна. Каждая — требует времени на разработку хотя бы в самом черновом варианте, дико медленном и обладающем кучей недостатков.
Результат: ради того, чтобы реализовать интересную идею необходимо потратить раз в 200 больше времени на вещи, которые к этой самой идее отношения не имеют вообще, но без них ее реализовать невозможно!
Более приземленно: допустим мы решили писать хороший алгоритм, например, морфологического анализа. Лексер кто писать будет? А словарь, без которого морфоанализатор работать будет... Хм, а не будет он работать
Так вот, в данном прокете, все элементы алгоритма перевода/интерфейса пользователя (кроме совсем уж базовых) легко заменяемы. Тогда, для приведенного примера, все что нужно сделать — это реализовать
только алгоритм морфологического анализа, использовав стандартный интерфейс и встроив его в мою программу. Экономия времени, я думаю очевидна?
Тебе не нравится мой словарь? Да флаг тебе в руки! Напиши нечто вроде прокси между лингво и моим переводчиком — и будет у тебя крутой словарь
P.S.: пример из жизни: когда я только начинал писать алгоритм синтаксического анализа на основе правил, мне пришлось потратить почти месяц на написание парсера файла с данными (имеющими сильно разветвленную структуру). При этом
даже через год я ловил в нем ошибки (в то время xml еще не был так популярен, да и писал я тогда на С++, что тоже сыграло большую роль). Однако сам алгоритм я написал в течение
4-х часов (правда без этих самых правил, этот алгоритм работать не мог)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Вчерне завершил все модификации в переводчике. Посмотреть переводчик и документацию к нему можно тут:
http://ertranslator.narod.ru/ERTranslateIt_25_02_2007.rar
На данный момент:
— все элементы алгоритма перевода представляются в виде интерфейсов
— все модули обработки загружаются динамически, таким образом, реализацию любой части алгоритма можно легко заменить на другую или добавить свой обработчик
С вопросами обращаться или тут, или по адресу
pankov2 at
mail.ru... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Возникла интересная проблема, может кто подкажет?
Суть: алгоритм перевода построен на цепочке вызовов функций-обработки предложений (ProcessString). Среди примерно десятка алгоритмов имеем такие:
1. алгоритм сортировки вариантов перевода слова в соответствии с предпочтением пользователя
2. алгоритм синтаксического анализа
Алгоритм синтаксического анализа выполняет определенные действия над словами в предложении, в частности — может добавить новое слово (соответственно, для этого слова берутся переводы из базы данных). И вот тут возникает следующая проблема: переводы нельзя отсортировать, т.к. синтаксический анализатор не знает о сортировщике (я надеюсь понятно почему? Т.к. сортировщик может написать кто угодно), а сортировщик — не знает о том, что синтаксический анализатор будет вставлять слова и более того — алгоритм сортировки применяется
до этапа синтаксического анализа
Как лучше решить эту проблему? А то у меня идей совсем нет...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
