Подтвердить что ты не робот

I18n - лучшие практики для интернационализации - XLIFF, gettext, INI,...?

EDIT: Мне бы очень хотелось увидеть общее обсуждение форматов, их плюсов и минусов!

EDIT2: "Баунти на самом деле не помогло создать нужную дискуссию, есть несколько интересных ответов, но исчерпывающий охват темы по-прежнему отсутствует. Шесть человек отметили вопрос в качестве фаворитов, что свидетельствует о том, что в этом обсуждении есть интерес.

При выборе интернационализации самая сложная часть IMO - это выбор формата хранения.

Например, Zend PHP Framework предлагает следующие адаптеры, которые охватывают почти все мои варианты:

  • Массив: нет, трудно поддерживать
  • CSV: не знаю, возможные проблемы с кодировкой
  • Gettext: часто используется, poEdit для всех доступных платформ, но сложный
  • INI: не знаю, возможные проблемы с кодировкой
  • TBX: нет подсказки
  • TMX: слишком большая вещь? никакие редакторы не доступны.
  • QT: не очень распространены, нет бесплатных инструментов
  • XLIFF: стандартный стандарт? НО не доступны бесплатные инструменты.
  • XMLTM: нет, не то, что мне нужно

В основном я застрял в 4 'смелых' вариантах. Я хотел бы использовать INI файлы, но я читаю о проблемах с кодировкой... это действительно проблема, если я использую строгие UTF-8 (файлы, соединения, db и т.д.)?

Я нахожусь в Windows, и я попытался выяснить, как poEdit работает, но просто не справился. В любом случае, нет учебных пособий в Интернете, gettext по-прежнему остается выбор или исчезающий вид?

Как насчет XLIFF, с кем-нибудь работал? Любые советы по использованию каких инструментов?

Любые идеи для интеграции Eclipse любой из этих технологий?

4b9b3361

Ответ 1

Всегда есть Translate Toolkit, которые позволяют переводить между ядром all указанными форматами и предпочтительным gettext (po) и XLIFF.

Ответ 2

POEdit на самом деле не сложно найти. Просто создайте новый файл .po, а затем скажите ему импортировать строки из исходных файлов. Программа сканирует ваши PHP файлы для любых вызовов функций, соответствующих _("Text"), gettext("Text") и т.д. Вы даже можете указать свои собственные функции для поиска.

Затем введите перевод в соответствующее поле. При сохранении вашего файла .po автоматически создается файл .mo. Это просто бинарная версия переводов, которая gettext может легко анализировать.

В вашем PHP script сделайте вызов bindtextdomain(), в котором сообщается, где находится ваш .mo файл. Теперь любые строки, переданные в gettext (или функция подчеркивания), будут переведены.

Это позволяет легко обновлять ваши файлы переводов. POEdit также имеет некоторые опрятные функции, такие как комментарии, отображение измененных и отброшенных строк и разрешение нечетких совпадений, что означает, что вам не нужно повторно переводить строки, которые были слегка изменены.

Ответ 3

вы можете использовать INI, если хотите, это просто, что INI не имеет возможности сказать кому-либо, что это в UTF8, поэтому, если кто-то откроет ваш INI с помощью редактора, он может повредить ваш файл.

Итак, идея состоит в том, что если вы можете доверять пользователю, чтобы редактировать его с помощью кодировки UTF8.

Вы можете добавить спецификацию в начале файла, некоторые редакторы знают об этом.

Что вы хотите сохранить? пользовательский контент или ресурсы вашего приложения?

Ответ 4

Я работал с двумя из этих форматов на стороне l18n: TMX и XLIFF. Они довольно похожи. TMX сейчас более популярен, но XLIFF быстро получает поддержку. Был, по крайней мере, один бесплатный редактор XLIFF, когда я в последний раз заглядывал в него: Transolution, но он не разрабатывается сейчас.

Ответ 5

Я сам занимаюсь хранением данных с использованием настраиваемого дизайна. Все отображаемые тексты хранятся в БД.

У меня две таблицы. Первая таблица имеет идентификационное значение, 32-символьное поле varchar (проиндексированное в этом поле) и английское описание этой фразы на 200 символов.

Моя вторая таблица имеет идентификатор из первой таблицы, код языка (EN_UK, EN_US и т.д.) и столбец NVARCHAR для текста.

Я использую nvarchar для текста, потому что он поддерживает другие наборы символов, которые я еще не использую.

32-символьный varchar в первой таблице хранит что-то вроде "pleaselogin", а вторая таблица фактически сохраняет полный "Пожалуйста, введите свой логин и пароль ниже".

Я создал огромный список динамических значений, которые я заменяю во время выполнения. Примером может служить "У вас есть [[dynamic: passworddaysremain]} дней, чтобы изменить пароль". - это позволяет мне работать над упорядочением слов на разных языках.

До сих пор мне приходилось иметь дело с арабскими цифрами, но мне придется что-то сделать для первого пользователя, который требует неарабских чисел.

Я фактически извлекаю эту информацию из базы данных по 2-часовому интервалу и кэширую ее на диск в файле для каждого языка в XML. Используется использование CDATA.

Есть много доступных опций: для производительности вы можете использовать html-шаблоны для каждого языка. Мой метод работает хорошо, но он часто использует XML DOM во время выполнения для создания страниц.

Ответ 6

Один довольно простой подход - просто использовать файл ресурсов и ресурс script. У таких программ, как MSVC, нет проблем с их редактированием. Они также достаточно дружелюбны к другим системам (и текстовым редакторам). Вы можете просто создать отдельные строковые таблицы (и растровые таблицы) для каждого языка и пометить каждую такую ​​таблицу на каком языке она находится.

Ответ 7

Ни один из этих вариантов выглядит очень аппетитно для меня.

Если вы отправляете файлы для перевода на нескольких языках, то вы хотите быть в состоянии доверять правильности кодировок, особенно если вы никого в своей команде не говорите на этих языках. Иногда бывает трудно определить проблему кодирования на иностранном языке, и слишком просто портить кодированные файлы, если вы позволите своей ОС "угадать".

Вам действительно нужен формат, который объявляет его кодировку. В противном случае переводчики или их инструменты перевода могут выбрать что-то другое, кроме UTF-8. Для моих денег лучше всего подходит любой простой XML-формат, но похоже, что вам нужно сыграть в Zend. XLIFF и TMX, безусловно, чрезмерны.

Формат, такой как ресурсы Java XML, был бы идеальным.

Ответ 8

Это может немного отличаться от того, что было опубликовано до сих пор, и, возможно, это не совсем то, что вы ищете, но я подумал, что добавлю его, если не использовать другой подход. Я пошел с объектно-ориентированным подходом. Я создал систему, которая инкапсулирует языковые файлы в класс, сохраняя их в массиве строк = > трансляции. Доступ к переводу осуществляется с помощью метода, называемого translate, с ключевой строкой в ​​качестве параметра. Расширение классов наследует массив родительского языка и может добавлять к нему или перезаписывать его. Поскольку классы расширяемы, вы можете изменить базовый класс и распространить изменения на дочерние элементы, что делает их более удобными, чем массив. Кроме того, вы вызываете только классы, которые вам нужны.

Ответ 9

Мы просто храним строки в БД и имеем встроенный в приложение режим транслятора для обработки фактических добавлений строк для разных языков.

В приложении мы используем различные трюки для создания текстовых идентификаторов, например

£("btn_save")
£(Order.class,"amt")

Перевод загружается из db при загрузке системы или при перезагрузке вручную. Метод £ заботится о просмотре переведенной строки в соответствии с языком, указанным в сеансе пользователя.

Ответ 10

Вы можете проверить мой l10n-инструмент под названием iL10Nz на http://www.myl10n.net

Вы можете загружать файлы po/pot, xliff, ini файлы, переводить, загружать.

вы также можете посмотреть это видео на YouTube http://www.youtube.com/watch?v=LJLmxMFxaxA

Спасибо Оливье