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

[i_chay]

Приветствую всех.

Михаил пишет:
> Начнём с цифр. Они могут работать в двух режимах, полном и
> каждая цифра просто одним словом. 

Еще можно читать цифры парами или тройками (т.е. группировать их)  -- уже не два режима. Что будем делать? Править исходники сервера?

> Когда это делает сервер, то у
> пользователя одна ручка для переключения, если это делает синтезатор, то
> пользователь должен править настройки каждого синтезатора. 

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

> Режимов
> обработки знаков препинания у нас тоже три, команду по их переключению
> получает тоже чисто сервер,. Нужно как-то пробрасывать эту
> настройку в синтезатор, если возложить такую работу на него. 

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

> Вспомним
> ещё про темп, высоту голоса и громкость. Их тоже лучше держать в одном
> месте.

"Держать в одном месте" (как это ни прикольно звучит) в аспекте удобства правки конфигурационных файлов пользователем  -- это не то же самое, что "обрабатывать в одном месте. См. выше.

> Если все эти
> функции с сервера снять, то вся цепочка окажется перегруженной передачей
> большого количества конфигурационной информации, чтобы до синтезатора
> дошёл режим пунктуации и цифр, 

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

> К тому же овчинка выделки не стоит. Сейчас у нас нет 
> никаких проблем с производительностью или стабильностью. 

Хорошо. Считаем, что их нет.  Но я говорил о других проблемах.

> сколько подборка правильной схемы использования возможностей
> ядра Linux. 

То есть, сервер к тому же непортируемый?

    Успехов. Анатолий.