Двуязычная (английская и португальская) документация в пакете R

Я пишу пакет для облегчения импорта бразильских наборов социально-экономических микроданных (перепись, PNAD и т.д.). Я предвижу две разные группы пользователей пакета:

  • Пользователи в Бразилии, которые могут чувствовать себя более непринужденно с документацией в Португальский. Вероятно, в некоторой степени он может понять английский, но иностранный язык, вероятно, сделает упаковку менее "Эргономичный".

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

Можно ли написать пакет так, чтобы документация была "двуязычной" (на английском и португальском), а язык, отображаемый пользователю, зависит от настроек страны/языка?

Кроме того,

Является ли это возможным в рамках документации для roxygen2?

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

РЕДАКТИРОВАТЬ: после предложения комментария я перечислил список r-package-devel. ЗДЕСЬ, затем следуйте ответам внизу. Дункан Мердок опубликовал интересный ответ, охватывающий некоторые из ответов @Brandons (ниже), но также включает в себя два дополнительных предложения, которые я считаю полезными:

  • есть пакет на одном языке, но виньетки для разных языки. Я буду следовать этому совету.

  • должны иметь версии пакета, скажем, 1.1 и 1.2, по одному на каждый Язык

Ответы

Ответ 1

В соответствии с Ropensci существует стандартный механизм для перевода документации пакета на неанглийские языки. Они описывают типичный процесс интернационализации/локализации следующим образом:

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

Поставки пакетов не-английская документация должна включать поле Language в DESCRIPTION файл.

И еще информация о поле Language:

A 'Поле языка может использоваться для указания, если пакет документация отсутствует на английском языке: это должен быть список , разделенный запятыми стандартного (не частного использования или grandfathered) тегов языка IETF как в настоящее время определяется RFC 5646 (https://tools.ietf.org/html/rfc5646, см. также https://en.wikipedia.org/wiki/IETF_language_tag), то есть использовать языковые subtags, которые по сути являются 2-буквенными ISO 639-1 (https://en.wikipedia.org/wiki/ISO_639-1) или 3-х буквенный ISO 639-3 (https://en.wikipedia.org/wiki/ISO_639-3).

Уход требуется, если ваш пакет содержит текст, отличный от ASCII, и, в частности, если он предназначен для использования в нескольких языковых стандартах. Можно отметить кодировку, используемую в файле DESCRIPTION и в файлах .Rd.

Что касается кодирования...

Сначала внимательно рассмотрите, если вам действительно нужен текст, отличный от ASCII. Многие пользователи R смогут только правильно просматривать текст в своем родном языковая группа (например, западноевропейская, восточноевропейская, упрощенная Китайский) и ASCII.72. Другие символы могут вообще не отображаться, отображается неправильно или вызывают ошибку в коде R. Для .Rd документация, маркировка кодировки и включая ASCII транслитерации, скорее всего, сделают разумную работу. Набор символы, которые обычно поддерживаются, шире, чем раньше около 2000, но нелатинские алфавиты (греческий, русский, грузинский,...) являются все еще часто проблематичны, и те, у которых есть символы двойной ширины (Китайский, японский, корейский) часто нужны специальные шрифты для правильно.

В соответствующей заметке R делает, однако, поддерживает "ошибки и предупреждения" на разных языках -" Есть < сильные > механизмы для перевода сообщений об ошибках и предупреждения R-и C-уровня. Доступны только в том случае, если R скомпилирована с поддержкой NLS (которая запрашивается опцией configure --enable-nls, по умолчанию).

Ответ 2

Помимо двуязычной документации, пожалуйста, позвольте мне дать следующий комментарий: Учитывая две ваши "целевые" группы, можно предположить, что некоторые из ваших пользователей будут работать с неанглийской ОС (как правило, Windows на португальском языке). При импорте данных временных рядов (или любых записей даты по сути) из-за различного форматирования "даты" (на английском и неанглийском языках) при импорте на английский язык могут появляться разные "результаты" (т.е. Записи с неправильной переносимостью)/неанглийские машины. У меня есть некоторый опыт работы с этими проблемами (я часто работаю с системами на чешском языке) и -другим, чем ad-hoc-кодированием, - я не нахожу простого решения. (Если вы найдете это вне темы, пожалуйста, не стесняйтесь удалять)