Давайте. Переводчик. Моно.

[Алексей Гринь]

Давайте забацаем свой переводчик. Хочу хитрое ядро, чтобы можно было легко втыкать языки. Хочу контексто-зависимый перевод.

Для начала предлагаю Эсперанто<=>Русский.

[Алексей Гринь]

Допустим, так:

using System;

namespace Lingvoforum.Language
{
    public enum Case
    {
        Abessive,
        Ablative,
        Absolutive,
        Accusative,
        Addirective,
        Adelative,
        Adessive,
        Adverbial,
        Antessive,
        Associative,
        Aversive,
        Benefactive,
        Caritive,
        Causal,
        CausalFinal,
        Comitative,
        Comparative,
        Dative,
        Direct,
        Distributive,
        DistributiveTemporal,
        Equative,
        Ergative,
        Essive,
        EssiveFormal,
        EssiveModal,
        Evitative,
        Final,
        Formal,
        Genitive,
        Inessive,
        Instructive,
        Instrumental,
        InstrumentalComitative,
        Intransitive,
        Intrative,
        Modal,
        Multiplicative,
        Nominative,
        Oblique,
        Ornative,
        Partitive,
        Pegative,
        Pertingent,
        Possessive,
        Postdirective,
        Postelative,
        Postessive,
        Postpositional,
        Prepositional,
        Privative,
        Prolative,
        Prosecutive,
        Proximative,
        Separative,
        Sociative,
        Subdirective,
        Sublative,
        Temporal,
        Terminative,
        Translative,
        Vialis,
        Vocative
    }
}

[Demetrius]

Ы-ы-ы-ы-ы... Вы уверены, что обязательно все языки так описывать?

А вообще, я с C# очень плохо знаком.

[Алексей Гринь]

И ещё:

    public enum Number
    {
        None,
        Singular,
        Dual,
        Plural
    }


    public enum Gender
    {
        None,
        Masculine,
        Feminine,
        Neuter
    }

Архитектуру думать надо. По уму у нас есть базовые обобщённые классы для существительных, прилагательных, и т. д. и каждый язык в собственных сборках должен реализовывать их сам. Чем лучше делать - интерфейсами или наследуемыми родителями?

Ы-ы-ы-ы-ы... Вы уверены, что обязательно все языки так описывать?

А вообще, я с C# очень плохо знаком.

Да, я именно хочу библиотеку, чтобы играться с языками. Чтобы можно было одно к другому лихо прикручивать.

А вообще, я с C# очень плохо знаком.

Учиться, учиться и ещё раз учиться! Моно можно компилить в натив (тогда рантайм не нужен), и там хорошая поддержка строк (самое главное-то), поэтому решение принято окончательное.

[Алексей Гринь]

Обязательно промежуточное представление какое-то. Что это может быть?

Ближе к "байткоду" или к "синтаксическим деревьям"?

[Алексей Гринь]

Ы-ы-ы-ы-ы... Вы уверены, что обязательно все языки так описывать?

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

[Demetrius]

Тогда уж:

    public enum Number
    {
        None,
        Singular,
        Dual,
        Trial,
        Quadral, //вроде бы нигде нет, но конлангеров не обижаем
        Paucal,
        GreaterPaucal,
        Plural,
        DistributivePlural
    }

    public enum Gender
    {
        None,
        Masculine,
        Feminine,
        Neuter
    }

А как же:

(wiki/en) Grammatical_gender#Australian_Aboriginal_languages
I — animate objects, men
II — women, water, fire, violence
III — edible fruit and vegetables
IV — miscellaneous (includes things not classifiable in the first three)

IMHO роды вообще стоит делать цифрами.

Архитектуру думать надо. По уму у нас есть базовые обобщённые классы для существительных, прилагательных, и т. д. и каждый язык в собственных сборках должен реализовывать их сам. Чем лучше делать - интерфейсами или наследуемыми родителями?

Не знаю. Я вообще проектировать программы нормально не умею.

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

Может, тогда оставить для морфологических категорий нумерацию?

Ближе к "байткоду" или к "синтаксическим деревьям"?

Байткод? Никогда о нём не думал...

Байткод — это типа хомская ядерная структура? Или как?


По мере возможностей, я участвую. Но C# я-таки плохо знаю.

[Алексей Гринь]

Тогда уж:

Добавил.

как же:
Цитата: Википедия

(wiki/en) Grammatical_gender#Australian_Aboriginal_languages
I — animate objects, men
II — women, water, fire, violence
III — edible fruit and vegetables
IV — miscellaneous (includes things not classifiable in the first three)

IMHO роды вообще стоит делать цифрами.

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

IMHO роды вообще стоит делать цифрами.

Тогда нельзя будет легко состыковать два языка, придётся писать мап-таблицы для каждой пары самостоятельно... А моя идея в том, что рантайм сам разрешает языковые соответствия и можно комбинировать Китайский > Татарский, Чукотский > Идо и т. д. без каких-либо усилий.

Может, тогда оставить для морфологических категорий нумерацию?

Не, это только запутает. Потом распишу идею подробнее.

Байткод? Никогда о нём не думал...

Байткод — это типа хомская ядерная структура? Или как?

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

Не знаю. Я вообще проектировать программы нормально не умею.

Тогда я пойду есть.

[myst]

Что-то ты не с того начал... Надо с алгоритма перевода начинать, мне кажется. Что будет в основе, статистика, словари или ещё что?

[Алексей Гринь]

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

Что будет в основе, статистика, словари или ещё что?

В идеале — wiki-словарь.

[Demetrius]

Тогда нельзя будет легко состыковать два языка, придётся писать мап-таблицы для каждой пары самостоятельно... А моя идея в том, что рантайм сам разрешает языковые соответствия и можно комбинировать Китайский > Татарский, Чукотский > Идо и т. д. без каких-либо усилий.

Так проблема в том, что род иногда обозначает вполне реальные вещи, а иногда это просто морфологическая характеристика, которую в переводе и не надо передавать.

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

Интересно. И как это будет выглядеть?
«Я–номинатив мгновенье¹–аккузатив помнить–прошлое, мгновенье¹ чудное, ты–женский-род я–фиг-знает-что-за-падежив явиться–прошлое». Так?

[myst]

В идеале — wiki-словарь.

Так он же для человека.

[Demetrius]

В идеале — wiki-словарь.

Так он же для человека.

По-моему, Алексей имел в виду не Wiktionary, а просто любой словарь на основе технологии вики. Или я не прав?

[arseniiv]

Боюсь я, что это никогда не закончится...

[Demetrius]

Боюсь я, что это никогда не закончится...

Что — это?

[злой]

Может, еще прикрутить состав слова и флексии для полного счастья?

[arseniiv]

Построение такого переводчика. Буду очень радоваться, когда что-нибудь получится работающее. Верю пока в возможность его создания.

[Michael Glazunov]

Давайте забацаем свой переводчик. Хочу хитрое ядро, чтобы можно было легко втыкать языки. Хочу контексто-зависимый перевод.

Так это же очень на идею языка-посредника похоже. Было много копий сломано, но мысль манит как магнит, согласен   

Надо бы тогда начать с того, что же такое словоформа и морфема раз уж что-то универсальное затеяли. Как будем проводить первый этап обработки - токенизацию? Ведь в русском и многих других есть пробелы, что отчасти облегчает эту процедуру, но в китайском, японском и многих других все пишется слитно. Я уже молчу про маргинальные случаи вроде чукотского, где совсем непонятно, что словоформа, а что морфема и как выделять эти единицы? Или полагаться будем на готовые NLP решения вроде Python'вского NLTK? 

[myst]

Случайно попалось: http://cmu-mt.blogspot.com/2008/07/improving-lexical-coverage-of-syntax.html

[Demetrius]

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

Ну, тут всё сравнительно просто. Для каждого языка будет свой модуль, который и будет дробить текст на слова и возвращать его в промежуточном представлении. Хотя с чукотским, конечно, будет сложно.

Насколько я понял, идея была такая: вся информация из служебных слов переносится в смысловые. То есть, если там было «весной на деревьях цветут цветы», то в промежуточном представлении будет «весна-Temporal дерево-Locative,pl цвести-... цветы-Nominative-pl». То есть, если я правильно понимаю идею, сохраняться только значимые слова.

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

[ettaine]

По поводу "вспомогательного языка":

(wiki/en) Universal_Networking_Language

[HackOnnerDib]

Хм. С си шарп тоже не знаком, так как пишу на си++ . Хотя это, в принципе, одно и то же.
Какая моя идея: не надо конвертировать исходную фразу в так называемый "машинный язык", или "язык-посредник".
Нужно определить, от какого слова к какому задается вопрос, а потом переводить предложение "на ходу".
То есть надо выделять окончания, суффиксы, анализировать и т.д. Такое написать удобнее на Лиспе(Lisp), нежели на си шарп(C#) и си++(C++).
А если вы решили создать МУЛЬТИЯЗЫКОВОЙ переводчик, то есть не только русский <=> эсперанто, то лучше сделать этим "посреднеческим" языком сам эсперанто.Не выдумывать старое, а взять самый легкий из естесственных(а так же плановых и искусственных) языков.

[arseniiv]

Умеют ли люди читать тему до написания своего сообщения?..

[Алексей Гринь]

Эх, пока особо времени нету. Посмотрим, как станется.

Боюсь я, что это никогда не закончится...

Тьфу-тьфу!

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

Например?

Нужно определить, от какого слова к какому задается вопрос, а потом переводить предложение "на ходу".

Ага, и получится Джон Баптист вместо Иоанна Крестителя...

[Алексей Гринь]

Пока разбираюсь с общим устройством, до самого парсинга текста далеко ещё...

В общем, есть абстрактные классы Language, Alphabet, которые должны реализовываться конкретными языками, в данном случае это пока RussianLanguage и RussianAlphabet.

Alphabet это объект, который содержит инфорацию о текущем алфавите. Есть такие методы у него:

Код Выделить Развернуть


        public abstract bool IsCharacter(char c);
        public abstract bool IsLetter(char c);
        public abstract bool IsPunctuation(char c);
        public abstract bool IsDigit(char c);


1) Он существует для валидации текста при токенизации. Т.е. "родные" слова переводятся, а внеалфавитные токены игнорируются и оставляются как есть.
2) Я не нашёл, можно ли с помощью встроенного CultureInfo "вытащить" набор символов внутри языка (на //stackoverflow.com говорят, что низзя), поэтому набор символов инициализируется вручную (обычные массивы чаров). Для языков типа русского это просто, для всяких китайских надо думать (наверное, просто читать с базы). Да и моно не факт, что поддерживает все возможные языки, лучше самим всё делать.
3) Встроенные .NET'овские char.IsDigit, char.IsLetter работают сразу на весь уникод, они не учитывают конкретно взятый алфавит. По крайней мере, я не нашёл иных способов. Кто знает, если можно - укажите. Т.е. для русского языка (сделано через поиск во вручную инициализируемом массиве):

Код Выделить Развернуть


var lang = RussianLanguage.GetLanguage();
Console.WriteLine(lang.Alphabet.IsDigit('२'));


напечатает False, а встроенное

Код Выделить Развернуть


Console.WriteLine(char.IsDigit('२'));


напечатает True, и язык ограничить никак нельзя (२ это число деванагари, а нам-то нужны только русские числа). Причём он такой интересный, не рассматривает китайское 三 как число. Не знаю, может, так прописано в Уникоде...
Поэтому, в общем, приходится велосипедить и индусить.

4) Языки инициализируются с аргументом (string kind), а "сорта" могут иметь разные алфавиты. Т.е. допустим для сербского можно было бы написать так:

Код Выделить Развернуть


var lang = SerbianLanguage.GetLanguage("Latin");


Тогда lang.Alphabet возвращал бы объект класса что-то типа SerbianLatinAlphabet (закастенное в просто Alphabet).

5) Что насчёт суррогатных пар? Суррогатные пары невыражаемы одним char'ом, тут уже нужны string'и. Как делают валидацию в этом случае?