Библиотеки для тру-локализации
Если коротко: нет.
вообще, больше похоже, что тебе нужен переводчик.
или непонятно, как ты собираешься "спрягать" и "синтезировать", например, слова "болит голова" в китайский язык?
или непонятно, как ты собираешься "спрягать" и "синтезировать", например, слова "болит голова" в китайский язык?
через словарик, очевидно. Вот только словарик должен быть контекстным в зависимости от того, самостоятельная эта фраза "болит голова" или вставляется в состав другой, более сложной. В последнем случае может быть несколько контекстов, в которых перевод и/или формы разнятся. Суть в том, что программист должен указать набор контекстов, а переводчик перевести фразу во всех формах, и передать её через файл ресурсов. При этом библиотека ответственна за то, что из контекста вычисляет список необходимых форм.
ну это вроде и есть переводчик
Идеальная система перевода, на самом деле, устроена очень просто, и при этом ей совершенно невозможно будет пользоваться.
Любая единица перевода состоит из:
1. Непосредственно самой строки
2. Списка контекстов
3. Параметров плейсхолдеров, которые влияют на плейсхолдеры.
4. Параметров плейсхолдеров, которые влияют на перевод.
Строку можно фиксировать. Точный список контекстов определить уже достаточно трудно: надо заранее знать, какая информация может влиять в разных языках на перевод слова "Exit". Даже для русского уже надо понимать, это кнопка "выход" или повелительное наклонение глагола в заголовке.
Параметры перевода тоже варьируются. Даже для обычных строк с числами, которые умеет gettext, в русском языке получается три варианта фразы. В строке может быть несколько чисел, добро пожаловать в степени тройки. Кроме того, есть ещё миллион параметров для разных языков: даже простое приветствие "доброе утро/день/вечер" совсем не напрямую транслируется в испанские "buenos días/tardes/noches". Соответственно, надо ещё передавать системе перевода реальное время. Если переводить на вьетнамский, то ещё и социальное положение того, к кому обращаешься. Таким образом, для хорошего перевода простой фразы "Доброе утро, %d слонов" нам надо передать уже минимум 4 параметра: точное время, количество слонов, их пол (во многих языках даже во множественном числе обращение будет отличаться в зависимости от полового состава и их социальный статус по отношению к вам. На самом деле параметров скорее всего понадобится ещё больше.
А ещё есть параметры для перевода самих плейсхолдеров. Например, мы хотим сказать: "Доброе утро, %name%". В русском и английском языке мы просто сделаем _(str).format(name для польского потребуется уже поставить в звательный падеж. А в кельтских языках, насколько я знаю, это самое name ещё и будет меняться в зависимости от того, какое слово в переводе окажется перед ним.
То есть, чтобы перевести фразу "Доброе утро, %d %name" на все языки мира, система перевода должна знать о фразе буквально всё. Это нереально. Поэтому переводимый текст упрощается, любых контекстных грамматических категорий стараются избегать как в оригинале, так и в переводе, и обходятся тем, что есть.
Любая единица перевода состоит из:
1. Непосредственно самой строки
2. Списка контекстов
3. Параметров плейсхолдеров, которые влияют на плейсхолдеры.
4. Параметров плейсхолдеров, которые влияют на перевод.
Строку можно фиксировать. Точный список контекстов определить уже достаточно трудно: надо заранее знать, какая информация может влиять в разных языках на перевод слова "Exit". Даже для русского уже надо понимать, это кнопка "выход" или повелительное наклонение глагола в заголовке.
Параметры перевода тоже варьируются. Даже для обычных строк с числами, которые умеет gettext, в русском языке получается три варианта фразы. В строке может быть несколько чисел, добро пожаловать в степени тройки. Кроме того, есть ещё миллион параметров для разных языков: даже простое приветствие "доброе утро/день/вечер" совсем не напрямую транслируется в испанские "buenos días/tardes/noches". Соответственно, надо ещё передавать системе перевода реальное время. Если переводить на вьетнамский, то ещё и социальное положение того, к кому обращаешься. Таким образом, для хорошего перевода простой фразы "Доброе утро, %d слонов" нам надо передать уже минимум 4 параметра: точное время, количество слонов, их пол (во многих языках даже во множественном числе обращение будет отличаться в зависимости от полового состава и их социальный статус по отношению к вам. На самом деле параметров скорее всего понадобится ещё больше.
А ещё есть параметры для перевода самих плейсхолдеров. Например, мы хотим сказать: "Доброе утро, %name%". В русском и английском языке мы просто сделаем _(str).format(name для польского потребуется уже поставить в звательный падеж. А в кельтских языках, насколько я знаю, это самое name ещё и будет меняться в зависимости от того, какое слово в переводе окажется перед ним.
То есть, чтобы перевести фразу "Доброе утро, %d %name" на все языки мира, система перевода должна знать о фразе буквально всё. Это нереально. Поэтому переводимый текст упрощается, любых контекстных грамматических категорий стараются избегать как в оригинале, так и в переводе, и обходятся тем, что есть.
Дай сообществу инструмент, и если твой продукт полезный, они сами всё переведут как им удобнее.
очень хороший ответ, при этом следует помнить, что переводом локализация не ограничивается:
- классический пример с разным порядком сортировки в немецкой энциклопедии и немецкой же телефонной книге;
- числа и даты форматируются в разных культурах по-разному;
- обращения (имена) формируются по-разному;
- компоненты почтового адреса имеют разный порядок;
etc
но и к переводу еще можно добавить прелести Right-To-Left языков (иврит, арабский особенности которых также необходимо учитывать при отображении информации.
- классический пример с разным порядком сортировки в немецкой энциклопедии и немецкой же телефонной книге;
- числа и даты форматируются в разных культурах по-разному;
- обращения (имена) формируются по-разному;
- компоненты почтового адреса имеют разный порядок;
etc
но и к переводу еще можно добавить прелести Right-To-Left языков (иврит, арабский особенности которых также необходимо учитывать при отображении информации.
- числа и даты форматируются в разных культурах по-разному;Ага, а еще в русском языке, например, есть числительное "полтора", о котором не знает даже Android API.
не уверен, что понял проблему
я вот пользуюсь GWT и вроде бы неразрешимых проблем не было: http://www.gwtproject.org/doc/latest/DevGuideI18n.html
я вот пользуюсь GWT и вроде бы неразрешимых проблем не было: http://www.gwtproject.org/doc/latest/DevGuideI18n.html
Оставить комментарий
yroslavasako
У меня появился чисто академический интерес - существуют ли библиотеки для полноценной локализации, не важно на каком языке и технологии они базируются. Почитал несколько статей о трудностях локализации, и в комментариях к каждой предлагались индивидуальные практики и велосипеды. Основную сложность я вижу в синтезированных сообщениях, правила спряжения в каждом языке свои, разное количество форм порождается в зависимости от рода, числа и т.п.В качестве самого трудного случая локализации я выделил создание полностью локализуемого MUD. Этот use case я использую как критерий минимальной пригодности системы локализации. Все библиотеки, что я нагуглил, этому критерию не удовлетворяют. Они представляют инструментарий, позволяющий несколько упростить локализацию в подобных случаях, но не решают вопрос полностью - генерацию сообщений всё равно придётся переписывать под конкретный язык.
Так что мне интересно, а она вообще существует, это универсальная библиотека?