Вход:  Пароль:  
FreeSource: Локализация/ПереводОписанийПакетов ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

Перевод описаний пакетов


О проблеме переводов описаний пакетов и способе её решения.


Более детально тему можно увидеть в рассылке devel@altlinux.ru. Ключевые слова: specspo, spec, specpot


Убедительная просьба к специалистам прокомментировать. Толкового описания я ещё не нашёл.


Оригинальная ссылка:
https://www.redhat.com/archives/rpm-list/2002-January/msg00346.html


Вот отголоски темы:


http://lists.altlinux.ru/pipermail/devel/2002-January/004647.html


http://lists.altlinux.ru/pipermail/devel/2002-November/007826.html
http://www.fedora.us/pipermail/fedora-devel/2003-July/001763.html
https://www.redhat.com/archives/fedora-devel-list/2003-July/msg00110.html


http://lists.altlinux.ru/pipermail/devel/2004-March/011434.html
http://lists.altlinux.ru/pipermail/devel/2004-August/012844.html


http://lists.altlinux.ru/pipermail/devel/2005-March/018814.html
http://lists.altlinux.ru/pipermail/devel/2005-March/018879.html


Вводное слово


В настоящий момент имеется пять основных систем упаковки пакетов и управления ими, применяемые в различных свободных дистрибутивах и системах:

Пакет является атомарной величиной дистрибутива, и имеет название (Summary в RPM) и описание (Description в RPM).

Текущие проблемы


В настоящий момент сложилась ситуация, когда описание пакета либо не переводится на другие языки вообще, либо перевод указывается в самом пакете (спеке в RPM). Как правило, имеется перевод хотя бы на один язык, в зависимости от региональной принадлежности производителя дистрибутива. Так, SuSE пишет описание на немецком, PLD – на польском, ALT – на русском, Mandrake – на французском. При этом англоязычное описание является де-факто стандартом. (mike)


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


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

Что имеется


Некие наработки на тему specpot/specpo (Vital Khilko?)
Переводы в имеющихся спеках


В Debian налажена веб-система перевода описаний: http://ddtp.debian.net/, http://kleptog.org/cgi-bin/ddtss2-cgi/ru Есть генерирование diff'ов в случае, если оригинальное описание было обновлено. Также перевод перед попаданием в репозитории проходит рецензию 2хчеловек.

Что предлагается


Создать общую для всех дистрибутивов базу переводов для пакетов всех дистрибутивов и исключить всяческие переводы из спеков. Для этого необходима координированная интеграционная работа между разработчиками дистрибутивов. Для хранения и работы с переводами предлагаются po-файлы, со всем сопутствующим инструментарием. Кодировка – UTF-8. Возможно также хранения переводов для Groups (хотя бы и как эталонных).


Примерный цикл жизни описания


На основании пакета (спека и пр) дистрибутивозависимой программой типа rpm2po формируется pot-файл, который передаётся в базу переводов, с указанием группы, к которой он принадлежит (Video и д.т.) Название pot-файла должно соответствовать официальному названию проекта (из mainstream) и обычно должно получаться
из текстового домена проекта (то название, которое используется для mo-файлов проекта при установке в систему). В случае, если установить такой невозможно, названием принимается название пакета.


Примерная структура хранилища базы переводов:

pot-файл отправляется в каталог C, как шаблон для перевода.
Сами переводы располагаются в соответствующем локали каталоге.
Для каждой локали есть файл all.po, который содержит строки, которые встречаются в нескольких пакетах.


При объединении переводов с pot-файлами применяется следующий алгоритм:
в po-файл отправляются только те строки, которые уникальны. Если строки повторяются для разных пакетов, они помещаются в all.po.
Это также снимет остроту проблемы разных названий для пакетов.
Возможно вообще не нужно разделять файл перевода на части
Далее мантейнер пакета или переводчик переводит описания.


Возможно это уже решено в rpm лучшим способом:
Далее переводы объединяются в один большой ru.po файл, (возможно будет и разбиение по названиям),
который подлежит упаковке в пакет package-info-i18n-локаль.


Возможно в RPM это уже сделано лучше:
Программы, работающие с переводами, должны использовать текстовый домен package-info, а лучше подключить библиотеку libpackage-info, возвращающую нужное описание для указанной локали и оригинала на английском.

Ключ поиска


Обычно использующие gettext проекты содержат в коде текст на рабочем языке авторов. В большинстве случаев таковым выбирают английский, но приходилось встречать также немецкий, французский и испанский. Po файлы состоят из записей, состоящих из ключевого фрагмента текста на языке оригинала и перевода на один язык. Однако, файлы spec имеют характерные ососбенности, позволяющие рационализировать эту схему и сами файлы spec.


Во-первых, spec имеют жестко определенный формат и всегда два переводимых фрагмента на каждый собираемый пакет.
Во-вторых, имена пакетов rpm всегда уникальны в пределах одного дистрибутива, и почти всегда совпадают в различных дистрибутивах, кроме случаев различного разбиения на подпакеты.
В-третьих, часто заполнение подлежащих переводу полей %summary и %description занимает более половины времени написания нового spec. Все остальные части шаблонны.
В-четвертых, текст описания вовсе не является постоянным. Пакеты, которые содержат набор мелких скриптов и вспомогательных программ, часто имеют описания, где перечисляется содержимое пакетов. Этот список меняется от версии к версии. Иногда в описания добавляются строки благодарности, отмечаются новые возможности программы и т.п.


Поэтому, есть предложение заменить текстовые описания пакетов в теле spec файлов макросами и использовать названия пакетов и подпакетов в качестве более стабильных и надежных ключей для извлечения текстов описаний на любом желаемом языке. Включая английский. Это позволит сократить объем spec и ускорить их написание, создаст возможность исправления ошибок и уточнения описаний на любом языке без пересборки, упростит проверку целостности общей базы переводов.

Ссылки по теме



Страницы, ссылающиеся на данную: Локализация/НациональнаяСпецификаСистемы
ТЗ/ИзмененияВМиреLinux


 
Файлов нет. [Показать файлы/форму]
Много комментариев (5). [Показать комментарии/форму]