Замены для gettext

Question

Мы используем gettext для переводов в нашем продукте, но у него было много проблем:

• Невозможно использовать язык, если система не поддерживает его.

В Solaris 9 Sparc, если мы сбросим среду на различные английские локали, сообщение все равно не будет переведено, если на машине нет соответствующей локали. Файл перевода присутствует, но мы не можем получить к нему доступ.

• Использует среду для разработки языка

Это вызывает проблемы на серверах, которые хотят переводить сообщения на разные языки. Теоретически, это может быть полностью поточно-ориентированная, распараллеливаемая операция, но gettext означает, что мы должны иметь глобальную блокировку вокруг перевода.

• Невозможно установить язык по умолчанию

Под этим я не подразумеваю текст в коде. Мы используем MsgID в коде, поэтому я хочу иметь возможность указать запасной перевод, к которому нужно перейти, если текущая среда, определяющая язык, недоступна. Но gettext не позволяет этого - я должен попробовать, а затем перезагрузить среду, прежде чем она будет предписывать смотреть на другой перевод. (Использование MsgID не было моим выбором - я хотел следовать стандартам gettext и использовать английский в качестве идентификаторов, но я был отвергнут, и было бы очень сложно изменить его сейчас)

• Кодировка, которая возвращается, варьируется между UTF-8 и текущей локальной кодировкой.

Я не имею в виду .po-файлы - они все в UTF-8 (раздражает, что msgfmt не обрабатывает BOM, но что угодно). Я имею в виду вывод gettext ngettext и т. Д., Которые находятся в UTF-8 (независимо от локальной / терминальной кодировки) в AIX и HPUX, но локальные в Solaris / Linux / FreeBSD, хотя это может быть связано с проблемами iconv?

В любом случае было бы неплохо не иметь специального кода для разных платформ - мне придется выяснить, смогу ли я получить bind_textdomain_codeset(domain,codepage);, чтобы помочь в решении этой проблемы.

---

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

Answer 1

Мы используем комплекты ресурсов ICU и очень довольны этим. Интерфейс ICU не «современный», но он мощный, основополагающие принципы надежны, а пакет ресурсов (с помощью инструмента genrb) довольно гибкий. Его возможности форматирования сообщений также хороши.

О ваших конкретных комментариях:

Невозможно использовать язык, если система не поддерживает его.

Я не понимаю этого. Это может быть связано с тем, что единственный «опыт», который я имею с gettext, - это чтение его документации.

Использование среды для разработки языка

Интерфейс ICU принимает Locale в качестве ввода, поэтому вы имеете полный контроль. Он также имеет понятие «локаль по умолчанию», если вам это удобнее.

Невозможно установить язык по умолчанию

ICU имеет сложный резервный механизм , включающий пакет по умолчанию

Кодировка, которая возвращается, варьируется между UTF-8 и текущей локальной кодировкой.

String ResourceBundle с (другие типы данных также возможны) всегда представлены как UnicodeString , который внутренне кодируется в UTF-16. UTF-32 с UnicodeString довольно прост, поскольку его интерфейс предоставляет несколько методов, позволяющих манипулировать им на уровне кода. Для других кодировок возможно преобразование кода .

Answer 2

1. Не могу использовать язык, если система не поддерживает его.

Неправильно. Вы можете вручную указать язык. Использование переменной окружения LANGUAGE

int main()
{
      setlocale(LC_ALL,"");
      setenv("LANGUAGE","foo");
}

Это работает, даже если локаль не существует (вы когда-нибудь видели язык foo?)

2. Использует среду для разработки языка

Что за проблема с этим? Это дает пользователю больше контроля.

3. Не могу установить язык по умолчанию

Неправильно, см. Выше.

4. Возвращаемое кодирование может варьироваться между UTF-8 и текущим локальным кодированием.

Неправильно, см. bind_textdomain_codeset(domain,codepage);

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

Есть еще один важный момент: отличная поддержка множественных форм, которая довольно плохо поддерживается в инструментах, не основанных на gettext.

---

Существует только 1 ограничение gettext - вы не можете использовать более одного языка для каждого процесса. Переключение языка не безопасно. К счастью, большинство программ для общения с людьми говорят на одном языке.

Это может быть ограничение только для многопоточных сервисов.

РЕДАКТИРОВАТЬ: Но даже это не реальная проблема . Я однажды реализовал многопоточную версию gettext для своего проекта. См. http://art -blog.no-ip.info / cppcms / blog / post / 16 , на основе mo чтения файлов.

Answer 3

Вы также можете преобразовывать пакеты ресурсов ICU в формат XLIFF на основе XML и обратно для перевода.

Answer 4

Невозможно использовать язык, если система не поддерживает его.

Это не имеет никакого отношения к GNU gettext - потому что оно обрабатывает только часть перевода. Но это правда, что если система не может отображать китайские иероглифы, у вас будут проблемы с Китаем.

Использует среду для разработки языка

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

Невозможно установить язык по умолчанию

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

Кодировка, которая возвращается, варьируется между UTF-8 и текущей локальной кодировкой.

Если вы в состоянии выбрать инструмент интернационализации, вы также можете выбрать, какую кодировку символов вы хотите использовать для своих текстов. Некоторые проекты используют utf-8 для всех языков (мои предпочтения), другие используют кодировку локали.

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

Нет, извините - я не вижу никаких проблем с gettext GNU: -)

Answer 5

Переключение языка в браузере Google Chrome сделано очень аккуратно. Возможно переключение между языками во время работы программы. Я не знаю, какую систему они используют, но, возможно, стоит изучить ее, поскольку это браузер с открытым исходным кодом.