Переводим SliTaz на русский язык. Часть 2

Продолжаем работать с Poedit.

Чем больше работаешь с программой, тем более понятной она становится. Иногда открываешь в ней какие-то интересные, неизвестные до этого, возможности. Я в прошлой статье писал, что мне больше от Poedit ничего не надо. Понадобилось.

Самый правильный путь перевода программ — создать новый (или обновить существующий) файл перевода, основываясь на исходниках программы. Таких переводов на текущий момент у меня уже 13 штук — asunder, galculator, gcolor2, isomaster, leafpad, lxapperance, lxpanel, lxtask, midori, mtpaint, nano, obconf и pcmanfm.

1. Загружаем исходники с сайта разработчика. Версия должна соответствовать установленной в системе. Иногда эту версию придется поискать...
2. Для пакетов я создал отдельную папку в своей домашней: /home/tux/packs/
3. Копируем туда тарбол с исходниками, распаковываем (правая кнопка мыши — Распаковать — Распаковать в текущую папку). Например, для lxpanel мы получим папку /home/tux/packs/lxpanel-0.5.5 с исходниками и другими файлами внутри.
4. Файлы переводов лежат у меня в /home/tux/l10n-ru, а сделанные из исходников, кроме того — в подпапке from-src. Теперь у меня будет не простой файл перевода (непонятно откуда взятый), а «фирменный» :) из исходников, переношу в папку from-src и открываю его в Poedit
5. Меню — Каталог — Настройки — вкладка «Пути». В одноименном окне записываем базовый адрес «/home/tux/packs/lxpanel-0.5.5». А ниже вписываем подпапки, в которых лежат исходники. Так уж получилось, что пример с lxpanel непрост, зато так можно будет показать все особенности. Открываем PCManFM и обследуем дерево папок. Исходные файлы, написанные на C имеют расширения *.c и *.h («заголовочные» файлы, header). На файлы Makefile.am и Makefile.in не обращаем ни малейшего внимания — они нужны только для сборки. Если «си»-шные файлы находятся и по базовому адресу, вписываем точку («.») в качестве пути (как-то раз было, но не в этой программе). Здесь вписываем папку src, это обычное место расположения исходников во многих пакетах. Далее. В ней имеется папка plugins — дописываем src/plugins в наш список, и так далее. Кроме «си»-шных есть еще и «глэйд»-овские файлы. Они имеют расширения *.glade и *.ui. Внутри них — xml, описывающий некоторые диалоговые окна. Добавляем папки, содержащие эти файлы так же в наш список.
   О существовании и назначении этих файлов я узнал случайно, когда для одной из программ получил просто «игрушечный», краткий список строк. Но, краткость, в данном случае — вовсе не сестра таланта :)
6. Если еще не были, то заходим — меню — Правка — Параметры — Парсеры. Убеждаемся, что в списке парсеров («разбирателей») исходного кода присутствуют «C/C++» и «Glade». Глэйда у меня не было, поэтому нажимаем «Новый» и вводим все те же параметры, что и во всех остальных парсерах, кроме первых двух полей ввода:

   Glade
   
   *.glade;*.ui
   
   xgettext --force-po -o %o %C %K %F
   
   -k%k
   
   %f
   
   --from-code=%c
   

   Похоже, что, раз настройки для разных парсеров одинаковые, то определение идет по расширению файла, что не есть «гут». Например, хоть я и добавил расширение *.ui в список, но программа на него ругается, говорит, неизвестный тип файла. Об этом — дальше, а пока просто закрываем — ОК — ОК. Сохраняем файл в Poedit.
7. Вот теперь — немного «шаманства», потому что сдается мне, что это никакая не фича, а баг :) Переходим в папки с исходниками. Все файлы с расширениями *.ui переименовываем в *.glade. Можно и вовнутрь заглянуть, и подкорректировать, если что. Строки, которые выбирает парсер, имеют свойство «translatable="yes"», вот пример:

   <property name="title" translatable="yes">Application Launch Bar</property>
   

   Таким образом я перевел в плагине «Панель быстрого запуска» пару строк, которые автор почему-то решил сделать непереводимыми. Теперь просто надо помнить, что к переводу нужно будет прикрепить и этот файлик.
   Переходим к работе с «си»-шными файлами. Переводимые строки здесь маркируются символами «_(», по этой сигнатуре можно их и искать. Вот пример:

   gtk_window_set_title( (GtkWindow*)dlg, _("Confirm") );

   Чтобы строки лучше «проглядывали» среди прочей программистской «премудрости», рекомендуется использовать текстовый редактор с подсветкой синтаксиса.
   Poedit автоматически коллекционирует эти строки. Но вот, бывает, что где-то в исходниках (не знаю, с какой целью) создается функция N_ и строки, соответственно, принимают такой вид:

   gtk_window_set_title( (GtkWindow*)dlg, N_("Confirm") );

   Парсер их коллекционировать отказывается. Не знаю, как это изменить в настройках, но я могу изменить исходники. Меняю я их только для того, чтобы собрать из них все строки. При компиляции измененных исходников, понятное дело, из них ничего хорошего не выйдет :) По хорошему стоило бы написать некий скрипт, но мой уровень мастерства значительно ниже этого. Итак, я открываю каждый файл *.c и *.h, ищу в них подстроку «_(» и, при необходимости, удаляю предшествующую букву «N».
   Теперь такие исходники можно скормить Poedit`у. Шаманству конец.
8. Возвращаемся в Poedit и нажимаем кнопку «Обновить каталог» (глобус, стрелки...) или меню — Каталог — Обновить из исходного кода. При обновлении Poedit покажет нам список новых и устаревших строк. Большое количество устаревших строк как раз может говорить о проблеме «N_(». После обновления у меня еще строки переводятся автоматически.
9. Вот теперь, кажется всё, что нужно для комфортной работы переводчика. Можно еще будет открыть свежесозданный (и сохраненный) файл *.po в текстовом редакторе и исправить наш «грубый хак» с переименовыванием *.ui в *.glade. Это стоит делать, если предполагается передать файл *.po кому-то. В файле *.po над каждой строкой стоит комментарий с текстом, откуда эта строка была извлечена, также иногда попадаются комментарии программистов для переводчиков (замечено в nano). Автоматические переводы облегчают работу, они помечаются специальным знаком и требуют обязательного пересмотра и подтверждения переводчика. Чем больше у нас будет качественных переводов, тем лучше будет работать автоматический перевод, только не забывайте обновлять его базу данных.

Сегодня мы научились создавать качественные файлы перевода из исходников, написанных на C/C++ и Glade. Приветствуются замечания и предложения, в первую очередь, позволяющие избежать «грубого хака».