Локализация 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