Лингвофорум

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

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

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

Цитировать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
    }
}

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

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

И ещё:

Цитировать
    public enum Number
    {
        None,
        Singular,
        Dual,
        Plural
    }


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

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

Цитата: Demetrius от мая  7, 2010, 19:40
Ы-ы-ы-ы-ы... Вы уверены, что обязательно все языки так описывать?

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

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

Цитата: Demetrius от мая  7, 2010, 19:40
А вообще, я с C# очень плохо знаком.

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

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

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

Цитата: Demetrius от мая  7, 2010, 19:40
Ы-ы-ы-ы-ы... Вы уверены, что обязательно все языки так описывать?

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

Тогда уж:

Цитировать
    public enum Number
    {
        None,
        Singular,
        Dual,
        Trial,
        Quadral, //вроде бы нигде нет (http://en.wikipedia.org/wiki/Grammatical_number#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 роды вообще стоит делать цифрами.

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

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

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

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

Цитата: Алексей Гринь от мая  7, 2010, 19:46
Ближе к "байткоду" или к "синтаксическим деревьям"?

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

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


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

Цитата: Demetrius от мая  7, 2010, 19:58
Тогда уж:

Добавил.

Цитата: Demetrius от мая  7, 2010, 19:58
как же:
Цитата: Википедия

Цитировать(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 роды вообще стоит делать цифрами.

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

Цитата: Demetrius от мая  7, 2010, 19:58
IMHO роды вообще стоит делать цифрами.

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

Цитата: Demetrius от мая  7, 2010, 19:58
Может, тогда оставить для морфологических категорий нумерацию?

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

Цитата: Demetrius от мая  7, 2010, 19:58
Байткод? Никогда о нём не думал...

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

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

Цитата: Demetrius от мая  7, 2010, 19:58
Не знаю. Я вообще проектировать программы нормально не умею. :-[

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

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

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

Цитата: myst от мая  7, 2010, 20:12
Что будет в основе, статистика, словари или ещё что?

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

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

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

Цитата: Алексей Гринь от мая  7, 2010, 20:10
Да не обязательно все эти теоретические изыски, просто некоторый вспомогательный язык (можно сказать, конланг), который бы легко парсился и был недвусмысленен.

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

Цитата: Алексей Гринь от мая  7, 2010, 20:17
В идеале — wiki-словарь.

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

Цитата: myst от мая  7, 2010, 20:35

Цитата: Алексей Гринь от мая  7, 2010, 20:17
В идеале — wiki-словарь.

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

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

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

Цитата: arseniiv от мая  7, 2010, 20:57
Боюсь я, что это никогда не закончится... :-\

Что — это?

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

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

Цитата: Алексей Гринь от мая  7, 2010, 19:03
Давайте забацаем свой переводчик. Хочу хитрое ядро, чтобы можно было легко втыкать языки. Хочу контексто-зависимый перевод.

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

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

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

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

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

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

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

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

(wiki/en) Universal_Networking_Language (http://en.wikipedia.org/wiki/Universal_Networking_Language)

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

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

Цитата: arseniiv от мая  7, 2010, 20:57
Боюсь я, что это никогда не закончится...

Тьфу-тьфу!

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

Например?

Цитата: HackOnnerDib от мая 15, 2010, 13:14
Нужно определить, от какого слова к какому задается вопрос, а потом переводить предложение "на ходу".

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

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

В общем, есть абстрактные классы 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'и. Как делают валидацию в этом случае?

Какую грамматику—представление использовать?

 :-[

Цитата: Алексей Гринь от мая 19, 2010, 03:56

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

Например?

Банальный пример: Postessive, Genitive.

Вот ещё: Instrumental (using a phone), Instructive (by [means of] phone), Prolative (by [the way of] phone), Vialis (by [the way of] phone; Википедия говорит, что Prolative и Vialis — одно и то же, в разных языках), InstrumentalComitative (using a phone).

IMHO проще сделать свой набор падежей. Типа CaseFrom, CaseTo. Падежей почти всегда мало, поэтому у них очень размытое значение. С предлогами легче, хотя и они многозначны.

Кроме того, некоторые будут применимы не во всех случаях. Например, «на Украине» — это Adessive или Inessive? ;)

Цитата: Алексей Гринь от мая 27, 2010, 06:07
Какую грамматику—представление использовать?

А какие бывают? :-[

Что-то меня терзают сомнения в подходе, ваще не с того края :) Однако в качестве эксперимента...
Я готов взять на себя какой-нибудь модуль, если что. По планам летом у меня должно быть времени выше крыши, но планы у меня меняются чуть быстрее, чем появляются...  :green:

Цитата: RawonaM от мая 27, 2010, 16:17
Что-то меня терзают сомнения в подходе, ваще не с того края :)

По-моему, тоже...

Цитата: RawonaM от мая 27, 2010, 16:17
ваще не с того края

Цитата: myst от мая 27, 2010, 16:41
По-моему, тоже...

Скажите уже, что это значит? :\

Во-первыха, не хочется углубляться в академику и бессмысленные теории.
Во-вторыха, подход упрощённо такой: модуль первого языка парсит текст в дерево, которое состоит из verb phrases, noun phrases и всего такого. Далее модуль второго языка пробегается по сгенеренному дереву и генерит текст. Что не так?

Программа = данные + алгоритм. Мисту усё не терпится алгоритм, а я пока думаю, как зафигачить данные. Тута ведь трабла в универсальности, нужно всё продумать так, чтобы большинство возможных языков легко вкрутилось. C# язык не функциональный, а ООП, поэтому тут нельзя думать об обобщённых алгоритмах, сперва не продумав обобщённые данные.

Цитата: Demetrius от мая 27, 2010, 16:10
Вот ещё: Instrumental (using a phone), Instructive (by [means of] phone), Prolative (by [the way of] phone), Vialis (by [the way of] phone; Википедия говорит, что Prolative и Vialis — одно и то же, в разных языках), InstrumentalComitative (using a phone).

Цитата: Demetrius от мая 27, 2010, 16:10
Типа CaseFrom, CaseTo.

В моей терминологии это NarrowCase и WidenCase :)
Синтаксическое дерево, которое должно передаваться из языкового модуля в модуль, всегда оперирует широкими падежами.

Допустим, есть финское talossa, это дом-ИНЕССИВ. Допустим, что ИНЕССИВ - это верх конкретики (т.е. широкий падеж), и оно так же и передаётся в синтаксическое дерево. В русском модуле должна быть таблица, которая сопоставляет широкие падежи со средствами русского языка (факультативный предлог + существительное * узкий падеж). Т.е., в русском языке инессив это "в + сущ. * PREP" (если для сущ. не указано иное). В контексте русского языка PREP является узким падежом, т.е. его назначение и смысл не являются сверхконкретизированными, он используется здесь только в контексте определённого языка, морфологически.

Сопоставление зависит конечно ещё от собственных характеристик существительного. Например, инессив для хаты был бы не в «в хате», а «на хате». Такая overriding-информация должна быть прописана в словаре.

Я пока не очень знаю, существует ли понятие "глагольное управление" на уровне универсального синтаксического дерева.
Мысля у меня такая, что verb phrase это собсно сам глагол + набор noun phrases с разными модификаторами (широкими "падежами" (которые могут раскрутиться в предлоги без узких падежей, в узкие падежи, предлоги с узкими падежами или в послелоги, допустим), широкими артиклями и т. д.). Так вот, если у глагола есть столько информации, то понятие глагольного управления, наверное, должно отсутствовать как атавизм узкопадежных языков?

Т.е., в русском допустим, «видеть» требует винительного падежа.
В универсальном же словаре «видеть» ничего не требует.
При переводе в универсальный «я вижу Маню» переводится как «видеть-(...) я-номинатив Маня-аккузатив». Мне не хочется вводить лишние сущности, поэтому всякие агенсы, эргативы — все должны маппиться на простые (семантические) номинативы/аккузативы.
Далее, в целевом языке идёт матчинг на глагол «видеть», который бы допускал при себе семантические аккузатив и номинатив. В английском это находится see. Далее падежи сужаются, ла-ла-ла, и получаем I see you.

Вот такая вот бредня.

Цитата: Demetrius от мая 27, 2010, 16:10
Вот ещё: Instrumental (using a phone), Instructive (by [means of] phone), Prolative (by [the way of] phone), Vialis (by [the way of] phone; Википедия говорит, что Prolative и Vialis — одно и то же, в разных языках), InstrumentalComitative (using a phone).

В таких случаях модуль для языка должен определять контекст.
1) Найти глагол и подсмотреть его управление. Может быть, by есть часть контракта с глаголом, тогда широкий падеж определяется просто по словарю.
2) В некоторых языках придётся делать hardcoded-сопоставление контекста.
3) Если ничего не удаётся, нужно fall back to most used, most generic wide case. Т.е. в этом случае, наверное, Instrumental (в случае с инессивом это был бы Locative).

Цитата: Demetrius от мая 27, 2010, 16:10
Например, «на Украине» — это Adessive или Inessive? ;)

«На Украине» это широкий инессив, но узкий адессив :) Информация об употреблении Украины с «на» должна храниться в словаре.

Цитата: Алексей Гринь от мая 27, 2010, 17:53
Во-первыха, не хочется углубляться в академику и бессмысленные теории.

Есть же разработанные решения. Зачем велосипедить?
Учёные мужи плотно над этим работают, их всё равно не переплюнуть. Лучше воспользоваться их наработками.

Как бы всякие Хаскели и Лиспы тоже идут из академий, но на них ничего полезного простому человеку не написано и не пишется. Лучше, имхо, думать в практически полезных категориях, чем пытаться скрестить грамматику с лямбда-исчислением (допустим), с комбинаторикой какой-нибудь или ещё каким бредом. Теория и практика разные вещи, точка.

Цитата: Алексей Гринь от мая 27, 2010, 17:53
Далее модуль второго языка пробегается по сгенеренному дереву и генерит текст. Что не так?

Я выше давал подвернувшуюся ссылку, она как раз намекает, что не всё так просто. А это только капля в море научной дискуссии по этому поводу.

Цитата: Алексей Гринь от мая 27, 2010, 18:02
Теория и практика разные вещи, точка.

Что может быть практичнее хорошей теории?

Цитата: Алексей Гринь от мая 27, 2010, 18:02
Как бы всякие Хаскели и Лиспы тоже идут из академий, но на них ничего полезного простому человеку не написано и не пишется.

Всё-то ты знаешь. :negozhe:

Я как-то давно делал переводчик с русского на эсперанто, всё прекрасно работало без всяких теорий :\

Идея понятна. Но что-то мне всё это кажется подозрительным... Мне почему-то кажется, что надо разобраться с тем, что такое широкие падежи. Описать функцию каждого. Потому что такой функции «в чистом виде» ни в одном языке Вы не найдёте.

Только вот что-то у меня подозрение, что структура будет недостаточно гибкой. Падежи заранее забиты в существительное, а какие-нибудь другие классы — нет.

Например, будет ли в классе существительных притяжательность, или будет «сандыкым» — «я-посессив сундук-номинатив»? А если будет, то будет ли она в широком смысле? «Сундук-наш-но-не-твой» будет? Есть ли такое в ЕЯ?

Где гарантия, что мы учтём все категории? И может статься, что некоторые категории будут совершенно бесполезны: так, не будет тюрских модулей, а системе всё равно придётся переводить «мой сундук» в «мой-посессив сундук-1ед.притяж.» И где гарантия, что это будет не бесполезный расход памяти?

Цитата: Алексей Гринь от мая 27, 2010, 18:05
Я как-то давно делал переводчик с русского на эсперанто, всё прекрасно работало без всяких теорий :\

И где же он? :) Чего ж мы тогда заново все начинаем? :)

Цитата: RawonaM от мая 27, 2010, 20:40
Чего ж мы тогда заново все начинаем? :)

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

Цитата: Demetrius от мая 27, 2010, 18:52
Только вот что-то у меня подозрение, что структура будет недостаточно гибкой. Падежи заранее забиты в существительное, а какие-нибудь другие классы — нет.

М-м-м. Гибкость тут ни при чём. То, что вы предлагаете - это синтаксический сахар. Т.е. как бы с ним приятнее, но обойтись можно легко. «сундук(я-поссессив)» это абсолютно то же самое.

Цитата: Demetrius от мая 27, 2010, 18:52
Например, будет ли в классе существительных притяжательность, или будет «сандыкым» — «я-посессив сундук-номинатив»? А если будет, то будет ли она в широком смысле? «Сундук-наш-но-не-твой» будет? Есть ли такое в ЕЯ?

Я думаю, тут надо разделять по функции.
1) По функции перевода. Мы должны уметь строить обобщённое, универсальное синтаксическое дерево, которое бы мог без труда читать любой модуль. Существительные + падежи-модификаторы (если пугает слово «падежи», можно думать о них как о «модификаторах») — это такая примитивная абстракция, к которой можно свести любую идею подобного вида. То есть смысл универсального дерева в том, чтобы уметь свести любую мысль к промежуточному построению, а потом распаковать промежуточную структуру обратно в мысль, но уже на другом языке. В этом плане притяжательность совершенно не нужна, здесь всё реализуется через NounPhrase («сундук(я-поссессив)»). Не стоит впихивать в корневые классы всё подряд. Можно например даже на уровне синтакс. дерева вообще отключить понятие «местоимения», ибо они реализуемы существительными легко. В общем, на этом уровне важно не описать, а перевести.
2) По функции «игры» с самим конкретным языком. Вот здесь никто не мешает сделать подкласс UzbekNoun, в который можно было бы вкрутить и притяжательность, и блекджеком со шл. Модуль во время перевода внутренне работает с притяжательностью — никто не мешает, но будь добр, при переводе мысли в «общественное достояние» избавься от всей этой «мишуры» (я бы назвал этот процесс языковым маршалингом). Не будем же мы из-за одного какого-нибудь вшивого конланга перелопачивать всю иерархию... На этом уровнее важнее описать, чем перевести.

Единственно, что падежи энумами не есть расширяемо. Но иначе нельзя, без чёткого понимания конечного числа модификаторов модули просто не смогут общаться друг с другом... Т.е. если язык А на публичный уровень введёт новый падеж  Пердитив (или ещё какой вид модификатора), то язык Б, читая дерево, не сможет определить смысл этого падежа, этого Пердитива — и попробуй машине объясни!

Поэтому нужно чётко определить минимально нужное число падежей, а более тонкие мысли выражать следует, комбинируя их (из + за = из-за), т.е. существительное просто может иметь на себя более чем один падеж в таких особых случаях.

Цитата: Demetrius от мая 27, 2010, 18:52
И где гарантия, что это будет не бесполезный расход памяти?

Я бы об этом думал в последнюю очередь.

Цитата: Demetrius от мая 27, 2010, 18:55
Потом, когда мы сделаем девятьсот девяносто девять языковых модулей, можно будет писать текст прямо во внутреннем представлении... Это будет сложно, нужно будет по словарю выбирать значение каждого слова, разрешать полисемию вручную, зато в конце можно будет получить довольно грамматный текст на тысяче языков.

Вот, кстати, проблемко со словарём. Словарь должен содержать два вида гнёзд: 1) сверхконкретизированные (старый-заброшенный-дом-с-приведением) 2) обобщённые (дом вообще).

Сверхконкретизированные нужно по идее хранить как сериализованные ветви синтакс. дерева, для случаев когда в языке для опр. термина — опа! — лакуна (или когда словарь тупо неполон).
Т.е. допустим, roommate будет описано как «сосед(комната-КАКОЙ-ТАМ-ПАДЕЖ)», тогда в русском будем иметь "сосед по комнате", а в языке кукарача даже если слово и есть, а просто в кукарачевском словаре отсутствует, то всё равно переводчик сослужит службу и выведет хотя бы "сосед по комнате", вместо "извините, не смог перевести".

Второй случай (дом вообще) — когда конкретизировать нельзя, ведём себя как обычный тупой переводчик.

Правильно мыслю?

p.s. У меня ещё мысль по контекстам. Каждое слово должно помечаться в словаре набором категорий (напр. "рука" и "нога" это "часть тела"). Когда переводчик анализирует слово, он выбирает тот перевод, чей контекст ближе к контексту близлежащих слов. Т.е. если где-то рядом говорилось про рыцарей, то скорей всего под "луком" имелось в виду оружие, а не растение... Здесь нужно хорошо соптимизировать, что-то насчёт глубины поиска (ибо категории могут иметь надкатегории, в рекурсию уйдёшь), как в шахматах...

Цитата: Алексей Гринь от мая 28, 2010, 00:28

ЦитироватьЧего ж мы тогда заново все начинаем? :)

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

Так где он таки? Можно почитать примеры переводов?

Я думаю, надо отказаться от фиксированных грамматических категорий. Иначе с таким подходом могут быть для некоторых пар языков очень корявые переводы из-за того, что внутренние представления фраз на них будут слишком разными. Надо сделать всё-таки что-то типа синтаксического дерева. Тогда при определённых усилиях со стороны модулей можно даже будет получать "художественный" перевод. Можно обойтись без дерева, помечая слова маркерами, которые могут иметь разное количество параметров, притом маркеров должно быть разных много. То есть, как тут маркеры, но без деления их на падежи и т. п..

Кстати, как дела с эллипсисом и подобными штуками? Будет ли сообразен перевод фразы «Давайте. Переводчик. Моно» переводу «Давайте переводчик моно»?

Цитата: arseniiv от мая 29, 2010, 19:02
Кстати, как дела с эллипсисом и подобными штуками? Будет ли сообразен перевод фразы «Давайте. Переводчик. Моно» переводу «Давайте переводчик моно»?

тут такой уровень что для 100%-правильного перевода нужен полноценный искусственный интеллект, тут уж извините

Цитата: Алексей Гриньинессив для хаты был бы не в «в хате», а «на хате».

А регистры тоже различать треба.
Ибо «на хате» это блатной сленг.

Цитата: Алексей ГриньТ.е., в русском допустим, «видеть» требует винительного падежа.
В универсальном же словаре «видеть» ничего не требует.
При переводе в универсальный «я вижу Маню» переводится как «видеть-(...) я-номинатив Маня-аккузатив». Мне не хочется вводить лишние сущности, поэтому всякие агенсы, эргативы — все должны маппиться на простые (семантические) номинативы/аккузативы.
Далее, в целевом языке идёт матчинг на глагол «видеть», который бы допускал при себе семантические аккузатив и номинатив. В английском это находится see.

А как различать русские «я вижу Маню» и «вижу Маню»? И переводить сие на English?
Прописыванием обязательных частей предложения?
Я тут проверил в гугляторе, так он I во втором ставит.
(А вот стал проверять не только Indicative Mood, тут-то он и скис:

Цитата: ОригиналВидел бы лес.
Видел бы это лес.

Цитата: ResultShould have seen the forest.
Should have seen a forest.

)

Цитата: Алексей Гринь(старый-заброшенный-дом-с-приведением)

Цитата: Алексей Гриньp.s. У меня ещё мысль по контекстам. Каждое слово должно помечаться в словаре набором категорий (напр. "рука" и "нога" это "часть тела"). Когда переводчик анализирует слово, он выбирает тот перевод, чей контекст ближе к контексту близлежащих слов. Т.е. если где-то рядом говорилось про рыцарей, то скорей всего под "луком" имелось в виду оружие, а не растение...

«Рыцарь кинул лук на луку седла, достал из кармана лук и стал смачно его жевать.»
Может, тогда уж сразу семантические деревья разворачивать?

Цитата: Bhudh от мая 30, 2010, 02:48
Ибо «на хате» это блатной сленг.

Да ну?

Цитата: Bhudh от мая 30, 2010, 02:48
А как различать русские «я вижу Маню» и «вижу Маню»? И переводить сие на English?
Прописыванием обязательных частей предложения?

Ничё сложного нет.

Цитата: Bhudh от мая 30, 2010, 02:48
В смысле (старый-заброшенный-дом-с-приведением-к-...?...)?

?

Цитата: Bhudh от мая 30, 2010, 02:48
«Рыцарь кинул лук на луку седла, достал из кармана лук и стал смачно его жевать.»

Искусственный, нереальный пример.

Цитата: Bhudh от мая 30, 2010, 02:48
Может, тогда уж сразу семантические деревья разворачивать?

?

Цитата: Алексей ГриньДа ну?

Лично я (носитель русского языка) никогда не скажу «Сижу на настоящей деревенской хате», если только действительно на крышу не залез.

Цитата: Алексей Гринь?

Ай-я-яй, «одеть» и «надеть», значит, нельзя путать, а «привидение» и «приведение» можно? :negozhe:

Цитата: Алексей ГриньИскусственный, нереальный пример.

А в учебниках мало искусственных примеров? Или всё Ваш транслейтор переводить не обязан? А уж распозиционировали-то его уже!‥

Цитата: Алексей Гринь?

То бишь не (только) жёсткие категории с элементами, а ещё и возможные смысловые корреляции типа «лук∈[овощ] <=> жевать» «лук∈[оружие] <≠> жевать» (символы <=> и <≠> означают вероятность/невероятность), поскольку корреляция «овощ <=> жевать» прописана в свойствах категории [овощ] (а также в категориях [фрукт], [мясо] и надкатегории [пища]).

Кстати, вот так делить слова на категории (но на мнооого вложенных, в целую иерархию), то есть раскладывать по понятиям (они ведь вполне могут быть вложенными; как там они называются, уже не помню; в эту же схему можно втолкнуть антонимы, синонимы, омонимы), может быть удобным — будет полная классификация слов языков для каждого модуля и слов метаязыка. Если в языке нет слова для «бабочки-капустницы», то отображённое в метаязык понятие «бабочка/капустная» переведётся как «бабочка» или «капустная бабочка». Так же можно будет при наличии терпения преобразовывать простые конструкции типа «light blue» в «голубой». Такая группировка слов притом естественна при работе человека с языком, что повысит натуральность перевода. Как?

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

Так SMF для того и создана.

Цитата: Алексей Гринь от мая 30, 2010, 03:57
Искусственный, нереальный пример.

Цитата: myst от мая 30, 2010, 15:52
У него часы на час отстают от Московского.

Хи-хи...

Цитата: Bhudh от мая 30, 2010, 12:07
Так SMF для того и создана.

Цитата: Bhudh от мая 30, 2010, 12:07
SMF

??? :o (Или это омоним?)

Блин, когда ж я перестану путать SMF, SWF и SMW⁈⁇⁉ :wall:

О. ;D Но всё равно SMW с переводчиками разве так сильно пересекается? Не лучше для переводчика придумать отдельный формат?

Так если семантические шшупальца уже готовы, можно и воспользоваться.

:donno:

Как-то упустил эту тему...

Цитата: Алексей Гринь от мая 28, 2010, 00:28

Цитата: Demetrius от мая 27, 2010, 18:52
Только вот что-то у меня подозрение, что структура будет недостаточно гибкой. Падежи заранее забиты в существительное, а какие-нибудь другие классы — нет.

М-м-м. Гибкость тут ни при чём. То, что вы предлагаете - это синтаксический сахар. Т.е. как бы с ним приятнее, но обойтись можно легко. «сундук(я-поссессив)» это абсолютно то же самое.

Ну как бы падежи тоже тогда можно почти все выкинуть.

Зачем «дом»-инессив, если можно «внутренняя часть» («дом»-притяжательность)?
Зачем «я-номинатив жить-настоящее время Минск-инессив», если можно «я-субъект (населяя Минск-объект) сейчас жить»?

Почему падежи — это базовая абстракция, а притяжательность — это мишура?

Цитата: arseniiv от мая 29, 2010, 19:02
Я думаю, надо отказаться от фиксированных грамматических категорий. Иначе с таким подходом могут быть для некоторых пар языков очень корявые переводы из-за того, что внутренние представления фраз на них будут слишком разными. Надо сделать всё-таки что-то типа синтаксического дерева. Тогда при определённых усилиях со стороны модулей можно даже будет получать "художественный" перевод. Можно обойтись без дерева, помечая слова маркерами, которые могут иметь разное количество параметров, притом маркеров должно быть разных много. То есть, как тут маркеры, но без деления их на падежи и т. п..

Согласен. ИМХО нужны квантитативные методы.

Я подумал, лучше на первый раз тупо захардкодить англ.-рус.

Предложенные в сабже масштабы не осилить без должной практики и времени.

Цитата: Demetrius от августа 16, 2010, 17:46
Почему падежи — это базовая абстракция, а притяжательность — это мишура?

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

Цитата: Demetrius от августа 16, 2010, 17:46
Зачем «дом»-инессив, если можно «внутренняя часть» («дом»-притяжательность)?

Маркеры берутся, чтобы было удобнее и полезнее, а не чтобы было логично и красиво.

Как бы всё это условности, а не самостоятельные факты.

Тогда понятно.

Кстати, для использования Semantic MediaWiki немножко мешает то, что все слова с большой буквы.

Кто мешает чуточку подправить код?
Чтоб было как в Викисловаре.

Как жалко что до сих пор не создали переводчик. 21-й век на дворе. :)

В общем, заявленные масштабы требуют много ресёрча. Будем делать конкретно rus-eng.
Первым шагом сделал простенький "деклинатор" для русского языка (делал ещё полгода назад как-то, may include bydlocode, ибо прототип).

Аттачу к сообщению. Поиграйтесь, что ли...

Внутри деклинатор сущ., прилагательные вроде тоже сделаны (не помню), глаголов нетути...
Требует дотнет; если сильно надо, могу скинуть стандалоне-версию, только весить будет под 1-2 мб.

Скриншот:
(http://s11.radikal.ru/i184/1008/1a/d091c5a2cb38.jpg)

Наконец-то собрался с духом, поставил себе дотнет и попробовал. Вроде бы всё работает без особых проблем.

Заметил только, что у "куча", "круча" неправильный Gen. pl.

Ещё потом поиграюсь.

Сначала сделайте годный переводчик с французского на интерлингву. Если и при такой упрощённой задаче ничего не получится, то чего говорить о падежах, стилях речи и прочих извратах.

Цитата: Alone CoderСначала сделайте годный переводчик с французского на интерлингву.

Лучше с окситанского на пьемонтский.

Надо брать готовый движок и допиливать. Одному с нуля сделать нереально.

Чего такие писькимасиськи?

Цитата: Alone Coder от сентября  9, 2010, 19:29
Сначала сделайте годный переводчик с французского на интерлингву. Если и при такой упрощённой задаче ничего не получится, то чего говорить о падежах, стилях речи и прочих извратах.

Делать перевод с одного языка, который не знаешь, на другой язык, который не знаешь — это очень-очень сложная задача, таки да рувэ нэ.

На самом деле, перевод на близкие языки достаточно нормально работает. Перевод с русского на беларусский настолько успешен, что ошибка/нестандартная форма, выдаваема переводчиком быстро успела распространиться. (http://community.livejournal.com/by_mova/589391.html).

Цитата: myst от сентября  9, 2010, 19:40
Надо брать готовый движок и допиливать. Одному с нуля сделать нереально.

А какой брать? Их не так-то много. Apertium?

Цитата: Demetrius от сентября 10, 2010, 10:43
А какой брать? Их не так-то много. Apertium?

Я не в теме. Если их немного, я бы познакомился со всеми и выбрал тот, который меньше придётся допиливать до поставленной цели.

На фордже (http://sourceforge.net/search/?words=machine+translation&type_of_search=soft&words=machine+translator&search=Search) куча проектов, связанных с переводом, но их просеивать надо. Там, чей поди, больше половины какие-нить памяти перевода и прочие локализаторские приблуды.