Comments 26
Очень хотелось бы увидеть хорошее решение для множественного числа. Может есть какой-то способ нормального использования? Ведь реально, мне кажется, что в каждом языке есть ограниченное количество вариантов. Хотя бы не для всех языков, но для какой-то большой группы. А то, в лучшем случае, предусматривают только для английского множественное число. И пролучается, что вместо "У меня есть 41 фантик от жвачки" выводится "У меня есть 41 фантиков от жвачки".
Другими словами, кто-нибудь знает где взять лингвистические изыски на эту тему?
Другими словами, кто-нибудь знает где взять лингвистические изыски на эту тему?
К сожалению, такое я делаю руками - то есть, для русского языка есть три формы (1 жвачка, 2 жвачки, 6 жвачек). В английском этой проблемы нет - там больше чем 1 - тогда просто добавляем s (или es).
Разумеется, тут еще нужно мучать переводчика, чтобы для нужного языка он рассказал правила множественных чисел и падежи (если есть).
Разумеется, тут еще нужно мучать переводчика, чтобы для нужного языка он рассказал правила множественных чисел и падежи (если есть).
Вот я и предположил, что существует определённый набор форм общих для большого набора языков. Допустим, для целых чисел существует 20 различных форм. В русском языке это вырождается в 3 различимые формы. В английском вырождается в 2.
Кстати, для русского есть ещё проблема (тоже стоит обратить внимание) с дробными числами. Например, правильно будет "У меня есть 38,1 грамма соли", объясняется так: "У меня есть тридцать восемь целых одна десятая грамма соли".
Кстати, для русского есть ещё проблема (тоже стоит обратить внимание) с дробными числами. Например, правильно будет "У меня есть 38,1 грамма соли", объясняется так: "У меня есть тридцать восемь целых одна десятая грамма соли".
Для русского, насколько я знаю, уже неоднократно реализовано превращение числа в строчную запись (тем же 1С - точно реализовано), а вот генерализация для N языков в общем - не задумывался. Наверное, в основном, потому, что для меня каждый язык переводится в зависимости от нужности, пока у меня светит английский, русский и финский, думаю, что в скором времени узнаю, как там с числами :))
Ну с дробными там есть много чудес. Для целых есть уже давным-давно (лет 10 уж как) gettext и табличка языков.
Для меня эта информация не нужна, но написано толково, поэтому ставлю +1 бал.
Про многоязычность в веб-приложениях было бы интересно почитать.
Про многоязычность в веб-приложениях было бы интересно почитать.
В Веб-приложениях это делается также - анализом HTTP запроса со стороны пользователя, можно RFC покурить на эту тему :)
А вот как хранить - мне нравился вариант от Microsoft, когда они все хранили в XML.
А вот как хранить - мне нравился вариант от Microsoft, когда они все хранили в XML.
Загляните в соседний топик: интерфейс админки для многоязычного сайта. Не совсем о том, но тоже может быть полезно.
Используйте, хотя бы попробуйте, стандартные средства типа gettext.
В дополнение к Вашему комментарию http://www.gnu.org/software/gettext/manu…
Присоединяюсь. Использование po файлов и задание языка относительно текущей локали давно доказало свою жизнеспособность в Линукс. А повсеместное использование UTF8 дало возможность истинной интернационализации. Перевод любой OpenSource программы при этом, с использованием средств типа KBabel не представляет никакой трудности :)
Хочется отметить, что 1 млн на русском было бы правильнее писать как 1 000 000,00.
А в целом хорошо написано.
А в целом хорошо написано.
Мне очень нравится как в Qt устроена работа с локализацией.
Хорошо написано, вот только есть один не освещённый нюанс: различие восприятия информации в разных культурах. Самый простой пример - чтение справа налево (не только внутри строки, но и в расположении контролов).
Несколько примечаний:
Запрещайте художникам использовать текст в графике
иначе перевод без графического редактора будет не возможен,
а у вас появится дополнительная работа по ее хранению и подгрузке.
Слово в 1 языке может заменятся в другом несколькими разными словами в зависимости от контекста использования -
лучше заводить отдельные константы для одного и того же слова или выражения если вы его используете в другом контексте.
Собираемые выражения:
функция перевода(строка1) + значениечисловое + значениестроковое + функция перевода(строка2)
заменяем на
формат(функция перевода("строка %d %s строка")) чтобы переводчик мог воткнуть значения в подходящее место.
Импорт текстовых данных (если он есть): не надейтесь что у пользователя данные в его локальном формате, всегда давайте возможность настроить - ему могли их прислать уже в текстовом виде.
Запрещайте художникам использовать текст в графике
иначе перевод без графического редактора будет не возможен,
а у вас появится дополнительная работа по ее хранению и подгрузке.
Слово в 1 языке может заменятся в другом несколькими разными словами в зависимости от контекста использования -
лучше заводить отдельные константы для одного и того же слова или выражения если вы его используете в другом контексте.
Собираемые выражения:
функция перевода(строка1) + значениечисловое + значениестроковое + функция перевода(строка2)
заменяем на
формат(функция перевода("строка %d %s строка")) чтобы переводчик мог воткнуть значения в подходящее место.
Импорт текстовых данных (если он есть): не надейтесь что у пользователя данные в его локальном формате, всегда давайте возможность настроить - ему могли их прислать уже в текстовом виде.
Не все функции форматирования поддерживают позиционные параметры :-( GNU GLibC превращает «printf("%2$d files in %1$d directories",10,1000);» в «1000 files in 10 directories», как с этим обстоят дела в других OS ?
Можно написать свою функцию в этом случае.
PS Честно не говоря не разу не сталкивался, чтобы не поддерживала.
PS Честно не говоря не разу не сталкивался, чтобы не поддерживала.
Я пишу в основном на .NET под Windows, поэтому вообще не особо люблю позиционные параметры. Обычно кусок кода с выводом сообщения выглядит так:
1. Получаю значение выражения для текущего языка в string (или StringBuilder, смотря какая замена предстоит)
2. Заменяю в нем шаблоны на текст функцией Replace (и реализую нужную логику подстановки количества чисел (фантик, фантика, фантиков)
3. Выдаю пользователю
1. Получаю значение выражения для текущего языка в string (или StringBuilder, смотря какая замена предстоит)
2. Заменяю в нем шаблоны на текст функцией Replace (и реализую нужную логику подстановки количества чисел (фантик, фантика, фантиков)
3. Выдаю пользователю
А чем плохо использование отдельных файлов ресурсов?
В общем случае, в приложении нужно для каждого языка иметь свои наборы текстовых фраз, графических файлов и звуковых файлов. Удобно и логично их объединять в один файл ресурсов и в таком виде поставлять пользователю.
XML-файлы тоже имеют право на жизнь, но придётся звуки и графику класть куда-то отдельно от этих файлов, а если перед отдачей локализации пользователю запаковывать это в какой-то свой формат, то получатся те же самые файлы ресурсов, только самодельные.
В общем случае, в приложении нужно для каждого языка иметь свои наборы текстовых фраз, графических файлов и звуковых файлов. Удобно и логично их объединять в один файл ресурсов и в таком виде поставлять пользователю.
XML-файлы тоже имеют право на жизнь, но придётся звуки и графику класть куда-то отдельно от этих файлов, а если перед отдачей локализации пользователю запаковывать это в какой-то свой формат, то получатся те же самые файлы ресурсов, только самодельные.
Фишка в возможности выбора языка приложения пользователем самостоятельно. Файл ресурсов такой возможности не даст - ресурсы грузятся в зависимости от локали. А людей, кто сидит на операционной системе с одной локалью, а программы хочет видеть в другой - достаточно ;)
Если переводить текст то gettext удобней.
Переводчику шлется ваше приложение, текстовый файл для перевода и редактор, который бесплатен и существует наверно под все распространенные платформы.
Он может переводить, вставлять свой перевод и видеть результат в конечном приложении
Когда закончит работу на выходе будет обычный текстовый файл, который легко переслать, добавить в систему контроля версий и т.п.
Если вагон графики, звука и видео то там все равно переводчики будут возится переводя по одному файлу и организация перевода обычно - высыпать исходное в две папки, в одной редактировать файлы и для контроля смотреть слушать оригиналы.
Переводчику шлется ваше приложение, текстовый файл для перевода и редактор, который бесплатен и существует наверно под все распространенные платформы.
Он может переводить, вставлять свой перевод и видеть результат в конечном приложении
Когда закончит работу на выходе будет обычный текстовый файл, который легко переслать, добавить в систему контроля версий и т.п.
Если вагон графики, звука и видео то там все равно переводчики будут возится переводя по одному файлу и организация перевода обычно - высыпать исходное в две папки, в одной редактировать файлы и для контроля смотреть слушать оригиналы.
забыли напомнить про множественные числа - {quer}y, {quer}ies и тп. Хотя самое сложное вовсе не интерфейс интернациолизировать. Здесь gettext помогает да и особо проблем с этой задачей не возникает. Проблемы возникают когда нарпимер есть сайт с текстами на двадцати языках - а тексты а базе...
Но. Так как эта задача решалась и решается повсеместно - крайне советую рассматривать существующие решения. Например в django есть мод для полной интернациолизации включая даже данные. Искать на googlecode.
Но. Так как эта задача решалась и решается повсеместно - крайне советую рассматривать существующие решения. Например в django есть мод для полной интернациолизации включая даже данные. Искать на googlecode.
Sign up to leave a comment.
Об интернационализации приложений