[Homeros] ветка украинского языка

[Michael Pozhidaev]

Анатолий, Ваши соображения весьма спекулятивны. Ниже конкретнее:

> Видите: никакой латиницы, кириллицы, английского и русского.

Нет, всё равно не понял, ну будет и латиница и кириллица, структура
данных другая, ну и что?

> Вопрос лишь в том, как поступить, если  существует пересечение двух множеств.
> Вы этот момент исключаете, задавая в конфигурационных файлах заведомо не пересекающиеся множества (хотя, конечно, за этим должен был бы следить сервер или его конфигуратор, а не сам пользователь).
> Но можно поступить по-другому: во-первых, алфавит можно было бы
> получать непосредственно от синтезатора 

Ну они этого не умеют. Точно также, как и нет единого соглашения, как
получить алфавит от синтезатора.

> (таким образом исключалась бы работа с конфигурационными файлами
> сервера). Понятно, что совсем правильно было бы получить от
> синтезатора идентификатор поддерживаемого алфавита 

Ну тоже нет на практике ничего такого.

>если есть подходящие стандарты для данной задачи).

Суть нашей проблемы пока в том и есть, что никто никаких стандартов не
предложил, мы чисто эмпирически подбираем удобное для себя поведение;


> Во-вторых, сервер (а лучше so-модуль) самостоятельно мог бы строить
> пересечения для имеющихся множеств и объединять синтезаторы по общим
> (наибольшим) пересечениям в группы. Соответственно, разности множеств
> и пересечения составляли бы подгруппы в этих группах. То есть
> синтезатор определялся бы парой группа+подгруппа (в принципе, рекурсию
> можно продолжать до первой пустой подгруппы, тогда это будет уже не
> пара, а бболее длинная цепочка).

Анатолий, пожалуйста, приведите примеры, непонятно.

> Активный синтезатор вычислялся бы для каждого слова. Слово обрабатывается посимвольно: если символ привел нас к синтезатору, то слово далее не обрабатывается, а озвучивается.
> Если не привел, то в обработку попадает очередной символ. Понятно, что разрешено только движение по нисходящей, т.е. если очередной символ  не попадает в текущую группу/подгруппу и в нижеследующие подгруппы, то это считается концом слова и обработка завершается, а  В качестве синтезатора используется тот, в подгруппе которого оказался предыдущий символ (если это была группа, то используется синтезатор по умолчанию для этой группы или синтезатор с наименьшей разностью).
> В итоге это будет обычный конечный автомат, только правила переходов
> сервер сформирует сам, на основе информации, получаемой от
> синтезаторов (ну или из конфигурационных файлов).

Необходимый атрибут конечного автомата -- множество его состояний. Какой
его вид Вы предполагали? Множество языков?
Если вВы хотите общаться в терминологии грамматик, то, пожалуйста,
определите их для ясности более чётко. К тому же, если речь идёт о
детерминированном автомате, то фактически он и работает внутри, всё дело
в том, что просто не называется правильно. У функции
TextProcessor::split() (daemon/core/TextProcessor.cpp, строка 21) есть и
переменная-состояние (currentLangId) и выполняет по сути она те же переходы. Если Вы
подразумевали всё-таки автомат недетерминированный, то его, конечно,
сейчас нет, опишите, чем он будет лучше.

Корень проблемы здесь в том, что это всё равно эвристика на удачу,
Степан явно просил такого не делать. Остальные три члена украинского
сообщества пока с этим были согласны. Поправте, если я не прав.

> Повторю еще раз, что, в общем случае, это не задача речевого сервера
> (даже деление текста на латиницу и кириллицу). Информацию о языке
> червер должен получать от клиента в рамках общей информации о
> контексте (надо сразу приучать клиентов делать это), а потом
> передавать эту информацию синтезатору или на основе этой информации
> подбирать синтезатор.

Ну по факту этого нет, с этим нужно мириться. Если языки не переключает
сервер, то кто это должен делать? К тому же у нас есть ещё такое
понятие, как "язык по умолчанию". Анатолий любит слушать цифры всегда
по-русски, я - языком предшествующего текста. Суть в том, что
определение языка, выбор синтезатора, выполнение текстовых
преобразований должны решаться где-то на одном уровне.

> Поэтому, если все-таки подобный функционал включается в сервер, то, на
> мой взгляд, реализовывать его имеет смысл как динамически
> подгружаемый/выгружаемый модуль, который при желании можно вообще не
> загружать и это не скажется на работоспособности сервера.

Ну заведите один язык, который будет ловить 100% символов, назначте ему
синтезатор и принципиально ничего не изменится. Но будет неудобно для
пользователя. Так как развёртка цифр и знаков препинания будет в одном
месте, выбор языка в другом и т. д. Знаки препинаний у нас ещё могут
быть в трёх режимах.

-- 
Michael Pozhidaev. Tomsk, Russia. E-mail: msp на altlinux.ru
Russian info page: http://www.marigostra.ru/