Локализация Ruby: i18n, g18n, gettext, padrino... - какая разница?
Будучи несколько новым для Ruby, я изучаю существующие библиотеки, чтобы делать то, что я обычно делаю на других языках сценариев, и я немного озадачен библиотеками локализации, которые могут быть доступны для чего-то, построенного поверх Sinatra/Sequel (Rails/AR немного упрям на мой вкус).
Теперь я столкнулся с парой (i18n, r18n, GetText), хотя эта страница wiki, и, по-видимому, есть дополнительная библиотека, используемая в Падрино (на основе i18n вещи из Rails?); и, видимо, намного больше.
За исключением очевидного (например, GetText mo/po style vs yml файлов), я несколько смущен относительно того, как эти параметры могут отличаться. Вики не указывают на многое в этом отношении, за исключением того, что они существуют; а не как они отличаются.
Добавление к этой путанице заключается в том, что, по сути, каждая часть документации, по-видимому, охватывает один из них (и обычно в контексте RoR). Более того, эти параметры не выглядят полностью несовместимыми друг с другом при ближайшем рассмотрении - в том смысле, что, если бы я это правильно понял, они могли бы понимать друг друга в значительной степени.
Может ли кто-нибудь здесь дать краткое и подробное объяснение/обзор этих библиотек и наметить разницу между ними? Некоторые указатели на производительность также приветствуются, если вы знаете о них (кроме тех, что были из документов fast_gettext, что мало соображает, учитывая то, что я не понимаю разницу между этими параметрами).
Ответы
Ответ 1
Я вижу, как эта ситуация запутывает, не зная какой-либо истории библиотек i18n/l10n в Ruby. Вероятно, я должен написать несколько слов, но сейчас я попытаюсь дать обзор с моей точки зрения:
Gettext является, пожалуй, самым старым игроком в этой игре, и он наследует и сильные и слабые стороны своей родословной, которая придумывается для мира с доминированием C. Он имеет большинство функций, которые нужны, поставляется с некоторыми инструментами поддержки, которых нет у других (например, редакторами настольных файлов), и широко используется в так называемом корпоративном мире.
Gettext как таковой определяет API, и есть в основном две библиотеки, которые реализуют его в мире Ruby, традиционном Ruby Gettext от Masao Mutoh и fast_gettext от Майкл Гроссер.
Ruby Gettext достаточно мощный и поставляется с множеством функций, которые вам могут понадобиться или не понадобиться. С другой стороны, fast_gettext gem фокусируется на сырой скорости и реализуется как блестящая, современная библиотека Ruby в стиле кода, которая легко взламывается, а автор - очень умный и поддерживающий человек. Из двух я лично настоятельно рекомендую fast_gettext.
I18n gem является результатом совлокальных усилий различных решений Ruby i18n/l10n, которые существовали несколько лет назад, и что все стремились заменить Gettext по разным причинам в этот момент времени. Полученный API I18n в основном охватывает требования и возможности всех решений i18n/l10n, которые были задействованы в то время, включая API Gettext. Итак, сегодня API Ruby I18n является супермножеством Gettext API с начала 90-х годов.
Сегодня драгоценный камень I18n является официальным решением поставляемым с Ruby on Rails, но это также возможно популярный в мире Ruby в целом.
Драгоценный камень I18n также делает его очень легким для расширения и добавляет такие вещи, как кеширование, другие механизмы хранения (такие как файлы Gettext po, таблицы базы данных, значение ключа магазины, по умолчанию - обычные файлы Ruby и YAML) и т.д., и он поставляется с количеством модулей для этого (но внешние или пользовательские модули могут быть легко обработаны, протестированы и интегрированный).
Существуют файлы перевода для более 70 языков (локалей) для строк, используемых Ruby on Rails (которые также полезны в других проектах), поддерживаемых сообществом.
Я ничего не могу сказать о R18n, за исключением того, что он был изобретен сразу после того, как I18n попал в его первый выпуск, и, насколько я помню, он возник из сообщества Merb. Это кажется довольно сильным в мире рубинов России, но я могу ошибаться со всеми этими утверждениями.
Итак, если у вас нет веских оснований для выбора любого другого решения, я настоятельно рекомендую использовать I18n.
Тогда, с другой стороны, это ничего не значит, потому что Я веду этот проект более или менее, так как он был изобретен.
Надеюсь, это поможет.
[EDIT] добавлены ссылки на различные ссылки
Ответ 2
I18n - основной поток.
R18n является альтернативой некоторым дополнительным функциям (переводу модели, синтаксическому сахару) и некоторой разнице в идеологии и архитектуре (гибкая расширяемость с помощью мощных фильтров).
G18n нужно добавить модельные переходы к I18n.
Padrino не является библиотекой i18n, это просто структура Sinatra со встроенным I18n.
Gettext - это старая концепция IMHO с очень уродливым форматом и проблема с плюрализацией. Во всяком случае, он не популярен в сообществе Ruby.
Ответ 3
Во-первых:
как писал svenfuchs, I18n
- это структура, которая предоставляет модули для многих подходов к переводу и интернационализации.
"gettext" - это всего лишь один из многих модулей.
Поэтому нет смысла использовать I18n
.
По умолчанию для приложения Rails используется использование I18n
с бэкэндом YAML, и я понимаю часть вашего вопроса, чтобы сравнить этот бэкэнд с другими.
IMHO существуют два основных различия между подходами gettext
и YAML
:
- поддержка жизненного цикла
- иерархия
Gettext
Одна идея gettext
заключается в том, что перевод приложения не является единственным событием, а процессом жизненного цикла.
Он построен для поддержки этого живого цикла.
gettext
предназначен для использования простого английского языка в качестве ключей для переводов. Поэтому идея состоит в том, чтобы написать приложение на английском языке и пометить весь текст, который нужно перевести, как правило, обернув его _()
.
В результате исходный код приложения легко читается на английском языке.
Затем программа сканирует весь исходный код и извлекает текст для перевода и создает репозиторий (файл .pot
) этих текстов.
В следующем шаге, и здесь идет живой цикл, репозиторий объединен с существующими переводами (файлы .po, по одному для каждого целевого языка) и отмечены новые или измененные элементы.
Зрелые редакторы поддерживают переводчиков, сосредотачиваясь на новых и измененных элементах. Кроме того, специальные словари могут поддерживать частичные автоматические переводы.
gettext
является плоским, что означает, что каждая ключевая фраза переводится ровно один раз в файлы перевода. Нет иерархии. Но есть контекст. В файлах переводов перечислены все позиции исходного кода ключевой фразы. Редактор, имеющий доступ к исходному коду, может отображать источник вместе с переводом (и некоторые из них).
Наконец, файлы .po
преобразуются в машиночитаемые формы быстрого доступа (могут быть .mo, классический стандарт или база данных или json или...)
YAML
YAML другая сторона иерархическая, поэтому ее легко иметь вариации переводов в разных контекстах.
I18n использует эту структуру для поддержки scopes
и использует текущий путь к файлу как область действия при использовании ключей, начинающихся с точки.
Нет информации, в которой ключ используется в проекте (ну, если он не используется автоматически, но ключ может использоваться в других местах явно).
Нет никакой информации, есть ли какие-либо изменения.
Если ваша среда IDE не поддерживает вас, разработчик должен найти нужное место для ввода ключа в YAML, и поиск в нем может быть громоздким.
В других ответах говорится гораздо больше.
I18n
Я намеренно сказал YAML, а не I18n, потому что I18n является основой для интернационализации (а не только для перевода), а YAML - только один возможный бэкэнд.
Множественная поддержка в I18n отличается от множественной поддержки ванильного gettext. У меня нет опыта, как они сотрудничают.
<сильные > Примеры
gettext с позиционными параметрами:
sprintf(
_('Do you really want to delete tour %1$s_%2$s? Only empty tours can be deleted!'),
tag, idx)
переводы - это текстовые файлы, но PO-редакторы предоставляют графические интерфейсы:
#: js/addDelRow.js:15
msgid "" "Do you really want to delete tour %1$s_%2$s? Only empty tours can be deleted!"
msgstr "" "Wollen sie die Spalte %1$s_%2$s wirklich löschen? Nur leere Spalten können "
"gelöscht werden."
YAML с параметрами:
Источник
<%= t('.checked_at', ts: l(checked_at), user: full_name) %>
перевод
от
en:
hotels:
form:
checked_at: „set to checked by %{user} on %{ts}"
к
de:
hotels:
form:
checked_at: "geprüft gesetzt am %{ts} von %{user}"
Заключение
YAML намного проще начать, особенно если у вас есть поддержка с помощью IDE.
Vanilla RAILS построена.
Это не родной язык. Первым переводом может быть любой язык.
С растущими проектами и несколькими языками мои файлы YAML имеют тенденцию к повторению (тот же перевод, разбросанный по иерархии) и отслеживание изменений, и поэтому новые переводы громоздки.
gettext нуждается в дополнительной инструментальной цепочке и, следовательно, более сложной настройке.
Он поддерживает весь жизненный цикл непрерывного перевода разрабатываемых приложений.
Он основан на исходном тексте на английском языке.
Я обычно использую лучшие части обоих, используя YAML для интернационализации (число и формат даты, возможно, имена моделей?) и gettext для перевода.
Ответ 4
Ответ Андрея, чтобы указать мне на r18n docs, которые в основном разбивают его на одну строку:
R18n использует иерархический, а не англо-ориентированный формат YAML для переводов по умолчанию.
Нашел это слайд-шоу от Андрея. Он по-русски, но теперь он имеет гораздо больше смысла (слайд 7-9, в частности, четкие различия между i18n и r18n):
http://www.slideshare.net/iskin/r18n