Локализация Ruby: i18n, g18n, gettext, padrino... - какая разница?
будучи несколько новым для Ruby, я изучаю существующие библиотеки, чтобы делать то, что я обычно делаю на других языках сценариев, и я немного озадачен библиотеками локализации, которые могут быть доступны для чего-то, построенного поверх Sinatra/Sequel (Rails/AR слишком самоуверен на мой вкус).
теперь я столкнулся с парой (i18n, r18n, GetText), хотя этой странице, и, по-видимому, есть дополнительная библиотека, используемая в Padrino (на основе вещи i18n от Рельсы?); и, по-видимому, еще много.
за исключением очевидного (т. е. gettext mo/po style vs YML files), я несколько смущен тем, как эти параметры могут отличаться. Вики не указывает на многое в этом отношении, кроме того, что они существуют; не то, как они отличаются.
добавление к этой путанице заключается в том, что по существу каждая часть документации, похоже, охватывает один из них (и, как правило, в контексте RoR). Более того, эти варианты не выглядят совершенно несовместимые друг с другом при ближайшем рассмотрении-в том смысле, что, если я правильно понял, их понять можно файлы друг друга в значительной степени.
может ли кто-нибудь здесь быть в состоянии дать быстрое и до точки объяснение/обзор этих библиотек и наметить разницу между ними? Некоторые указатели на производительность также будут приветствоваться, если вы знаете о них (кроме тех, из документов fast_gettext, которые имели мало смысла, учитывая мой недостаток понимания разницы между этими вариантами).
4 ответов
Я вижу, как эта ситуация запутывает, не зная истории библиотек i18n/l10n в Ruby. Вероятно, я должен написать несколько слов об этом, но сейчас я попытаюсь дать обзор с моей точки зрения:
Gettext является, очевидно, старейшим игроком в этой игре, и он наследует как сильные, так и слабые стороны от своего предка, который изобретается для мира с доминированием C. Он имеет большинство функций, которые нужны, поставляется с поддержкой некоторых инструментов, которые другие отсутствуют (например, настольные Редакторы файлов po) и широко приняты в так называемом корпоративном мире.
Gettext как таковой определяет API и есть в основном две библиотеки, которые реализуют в мире Ruby, традиционный Ruby Gettext пакеты Масао Для Mutoh и fast_gettext gem by Майкл Гроссер.
Ruby Gettext довольно мощный и поставляется много функций, которые вы можете или может не понадобиться. С другой стороны, fast_gettext Gem фокусируется на необработанной скорости и реализуется как блестящая современная библиотека Ruby в стиле кода, которая легко взломать, а автор-очень умный и поддерживающий человек. Из двух я лично настоятельно рекомендую fast_gettext.
на гем i18n является результатом совместных усилий различных решений Ruby i18n/l10n, которые существовали несколько лет назад, и которые все стремились заменить Gettext по различным причинам момент времени. Полученный API I18n в основном охватывает требования и использования всех решений i18n/l10n, участвующих в то время, включая API Gettext. Итак, сегодняшний API Ruby I18n-это надмножество API Gettext с начала 90-х годов.
сегодня драгоценный камень I18n является официальным решением, которое поставляется с Ruby on Rails, но это тоже наверное самые популярные один в рубиновом мире в целом.
самоцвет I18n также делает это очень легко расширить featureset и добавлять такие вещи, как кэширование, другие механизмы хранения (например, файлы gettext po, таблицы баз данных, хранилища ключей; по умолчанию для хранения файлов Ruby и YAML) и т. д. и он поставляется с количество модулей для этого (но внешние или изготовленные на заказ модули можно легко произвести, испытать и интегрировать).
есть файлы перевода для 70+ языков (локали) для строк, используемых Ruby on Rails (которые полезно и в других проектах), поддерживаемых сообществом.
Я не могу много рассказать о R18n за исключением того, что он был изобретен сразу после того, как i18n попал в свой первый релиз, и, насколько я помню, он возник из сообщества Merb. Кажется, в русском рубиновом мире это довольно сильно, но я могу ошибаться во всех этих утверждениях.
Итак, если у вас нет очень веской причины выбрать любое другое решение, я настоятельно рекомендую использовать Как i18n.
затем с другой стороны это ничего не значит, потому что я руководил этим проектом более или менее с тех пор, как он был изобретен.
надеюсь, это поможет.
[EDIT] добавлены ссылки на различные ссылки
I18n является основным потоком.
R18n-это альтернатива с некоторыми дополнительными функциями (переводы моделей, синтаксический сахар) и некоторой разницей в идеологии и архитектуре (расширяемость flex мощными фильтрами).
G18n нужно добавить модель transtions в i18n.
Padrino не является библиотекой i18n, это просто Sinatra framework со встроенным I18n.
Gettext-это старая концепция IMHO с очень уродливым форматом и проблемой плюрализации. В любом случае, это не популярный в сообществе Ruby.
первый:
как писал svenfuchs,I18n - это структура, которая предоставляет модули для многих подходов к переводу и интернационализации.
"gettext" - это всего лишь один из многих модулей.
так что нет никаких вопросов, чтобы использовать I18n.
настройка приложения Rails по умолчанию-использовать I18n с бэкэндом YAML, и я понимаю часть вашего вопроса, чтобы сравнить этот бэкэнд с другими.
Имхо есть два основные различия между gettext и YAML подходы, основанные:
- поддержки жизненного цикла
- иерархия
gettext
одна идея gettext является то, что перевод приложения не является единичным событием, но процесс жизненного цикла.
Он построен для поддержки этого жизненного цикла.
gettext предназначен для использования простого английского языка в качестве ключей для переводов. Так что идея написать приложение в английский и Марк весь текст, который должен быть переведен, как правило, путем обертывания его с _().
В результате, исходный код приложения легко читается на английском языке.
затем программа сканирует весь исходный код и извлекает текстовые файлы для перевода и создает хранилище (the .pot файл) этих текстовых сообщений.
на следующем шаге, и вот идет видео, репозиторий слил С существующие переводы (.по!--43--> файлы, по одному для каждого языка) и новые или измененные пункты отмечены.
зрелые редакторы поддерживают переводчиков, фокусируясь на новых и измененных элементах. Кроме того, специальные словари проекта могут поддерживать частичные автоматические переводы.
gettext и квартира, что означает, что каждая ключевая фраза переводится ровно один раз в файлах перевода. Нет никакой иерархии. Но есть контекст. В файлы перевода, все позиции исходного кода ключевой фразы перечислены. Редактор с доступом к исходному коду может отображать Источник вместе с переводом (и некоторые делают).
наконец, .po файлы переводятся в машиночитаемые формы быстрого доступа (может быть.МО, классический стандарт, или база данных или json или ...)
в YAML
YAML с другой стороны является иерархическим, поэтому легко иметь вариации переводы в разных контекстах.
I18n использует эту структуру для поддержки scopes и использует текущий путь к файлу в качестве масштаба при использовании ключей, начинающихся с точки.
Нет информации, где ключ используется в проекте (ну, если авто область действия, но ключ может использоваться в других местах явно).
Нет никакой информации, есть ли какие-либо изменения.
Если ваша IDE не поддерживает вас, разработчик должен найти правильное место для размещения ключа в YAML и поиск использования может быть громоздким.
Много сказано в других ответах.
как i18n
я намеренно сказал в YAML, а не как i18n, потому что как i18n является основой для интернационализации (не только перевода), и в YAML только один возможный бэкэнд.
Поддержка множественного числа в I18n отличается от поддержки множественного числа vanilla gettext. У меня нет опыта, как они сотрудничать.
примеры
gettext с позиционными параметрами:
sprintf(
_('Do you really want to delete tour %1$s_%2$s? Only empty tours can be deleted!'),
tag, idx)
переводы являются текстовыми файлами, но Po-Редакторы предоставляют GUIs:
#: 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}“
to
de:
hotels:
form:
checked_at: "geprüft gesetzt am %{ts} von %{user}“
вывод
в YAML начать намного проще, особенно если у вас есть поддержка IDE.
Vanilla RAILS имеет встроенный.
Нет уроженца язык. Первым переводом может быть любой язык.
С растущими проектами и несколькими задержками мои файлы YAML имеют тенденцию к повторению (тот же перевод, разбросанный по иерархии) и отслеживанию изменений, и поэтому новые переводы громоздки.
gettext требуется дополнительная цепочка инструментов и, следовательно, более сложная установка.
Он поддерживает весь жизненный цикл непрерывного перевода развивающихся приложений.
Он основан на английском исходном коде.
я обычно использую лучшие части обоих, используя YAML для интернационализации (формат номера и даты, возможно, имена моделей?) и gettext для перевода.
ответ Андрея, чтобы указать мне на r18n docs, которые в основном разбивают его на одну строку:
R18n по умолчанию использует иерархический, а не английский формат YAML для переводов.
нашел это слайд-шоу от Андрея. Это на русском языке, но теперь это имеет гораздо больше смысла (слайды 7 до 9, в частности, четкие различия между i18n и r18n):