Локалізація програмних засобів/Технічні аспекти локалізації/Формати файлів перекладних рядків
Щоб перекласти рядок, локалізатор (здебільшого) не торкається виконуваних файлів відповідної програми. Натомість, перекладні рядки зберігаються й використовуються програмою з окремого файлу. Різні програми використовують різний формат такого файлу.
Типові формати файлу перекладу ред.
Формат .po ред.
Ці файли уже більше десяти років є стандартними файлами перекладу вільних програмних засобів (і не лише ВПЗ). Що принесло їм популярність? Надзвичайна простота: скрипти, додані до джерельного коду програми, створюють шаблон для перекладу (файл .pot), заповнюючи який, перекладач створює файл перекладу (файл .po). Приклад:
Файл шаблону (.pot):
# SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR This_file_is_part_of_KDE # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: http://bugs.kde.org\n" "POT-Creation-Date: 2009-07-30 06:55+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <kde-i18n-doc@kde.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: kfortunoid.cpp:105 msgid "Cannot find " msgstr "" #: kfortunoid.cpp:224 msgid "Fortunoid Settings" msgstr "" #. i18n: file: form/fortunoidsettings.ui:26 #. i18n: ectx: property (text), widget (QLabel, label_3) #: rc.cpp:3 msgid "arguments" msgstr "" #. i18n: file: form/fortunoidsettings.ui:40 #. i18n: ectx: property (text), widget (QLabel, label) #: rc.cpp:6 msgid "delay quote (sec)" msgstr ""
Файл перекладу (.pot):
# translation of plasma_applet_fortunoid.po to Ukrainian # Copyright (C) YEAR This_file_is_part_of_KDE # This file is distributed under the same license as the PACKAGE package. # # Yuri Chornoivan <yurchor@ukr.net>, 2009. msgid "" msgstr "" "Project-Id-Version: plasma_applet_fortunoid\n" "Report-Msgid-Bugs-To: http://bugs.kde.org\n" "POT-Creation-Date: 2009-07-30 06:55+0200\n" "PO-Revision-Date: 2009-04-29 18:16+0300\n" "Last-Translator: Yuri Chornoivan <yurchor@ukr.net>\n" "Language-Team: Ukrainian <translation@linux.org.ua>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Lokalize 0.3\n" "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%" "10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n" #: kfortunoid.cpp:105 msgid "Cannot find " msgstr "Не вдалося знайти " #: kfortunoid.cpp:224 msgid "Fortunoid Settings" msgstr "Параметри фортуноїда" #. i18n: file: form/fortunoidsettings.ui:26 #. i18n: ectx: property (text), widget (QLabel, label_3) #: rc.cpp:3 msgid "arguments" msgstr "аргументи" #. i18n: file: form/fortunoidsettings.ui:40 #. i18n: ectx: property (text), widget (QLabel, label) #: rc.cpp:6 msgid "delay quote (sec)" msgstr "затримка цитати (у сек.)" #~ msgid "no quote" #~ msgstr "немає цитати" #~ msgid "fortune not found" #~ msgstr "fortune не знайдено" #~ msgid "show background" #~ msgstr "показувати тло"
Декілька коментарів: перші декілька рядків (до #: kfortunoid.cpp:105) визначають заголовок файлу перекладу. У заголовку визначаються важливі параметри перекладу (ім’я перекладача, права поширення перекладу, дата створення шаблону перекладу та дата самого перекладу, адреса, куди користувачі мають надсилати повідомлення про вади у перекладі, і ще дві абсолютно важливі речі: кодування (charset) перекладу і форми множини мови (Plural-Forms). Хоча Unicode повсюдно переміг, залишається ще повно файлів у інших кодуваннях. Приклади: файл перекладу Freeciv мають кодування KOI8-U. Врегульовується це питання за допомогою команди:
iconv -f koi8u -t utf8 файл_перекладу.po>новий_файл.po
Але, увага, не забудьте відповідним чином змінити рядок
Content-Type: text/plain; charset=UTF-8
Якщо ви вирішите не довіряти долю свого перекладу ніяким хитромудрим програмкам, які писала зовсім незнайома вам людина і надасте перевагу теплому ламповому Vim, вам доведеться повписувати все це руками. Програми-помічники самі вписують потрібні дані (найкраща з цих програм зробила це у цьому випадку так: X-Generator: Lokalize 0.3).
Компіляція ред.
Після завершення перекладу програми з файлу .po командою (в загальному випадку)
msgfmt -o назва_програми.mo файл_перекладу.po
створюється файл (файл .mo), зрозумілий системі перекладу Linux (gettext), який і буде прочитано програмою під час завантаження. Такі файли зберігаються у /usr/share/locale/uk/LC_MESSAGES Для запису до цієї теки потрібні права доступу адміністратора.
Lokalize 1.0 здатен владнати справу (тимчасово) простіше. Програма записує файли до локальної теки користувача. Для перевірки перекладу вам не потрібні будуть права адміністратора.
Але корисність файлів PO виходить за межі простого перекладу інтерфейсу програм. За допомогою цих файлів (звичайно ж, без перетворення на MO-файл) можна перекладати документацію, сайти, корисні системні файли тощо.
Простота файлів PO сполучається з граничною гнучкістю. Як ви можете помітити, рядки, що починаються з символу # є коментарями (окрім одного особливого випадку, про який поговоримо пізніше), отже у них можна записувати корисні для перекладача і програми обробки дані. Крім того, за належної обробки зберігаються навіть застарілі рядки, які вже було перекладено (хто знає, а раптом ще згодяться). Ці рядки записано наприкінці файла перекладу.
В окремих проектах існують особливості уживання файлів .po, їх розглянуто у розділі, що стосуються цих проектів.
Формат .ts (проект Qt) ред.
Бібліотека Qt має власну систему перекладу інтерфейсів програм, власний формат файлів пам’яті перекладів і власні теки для зберігання таких перекладів.
Отже основним матеріалом, з яким має справу перекладач, є файл .ts. Приклад:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE TS>
<TS version="2.0" language="uk_UA">
<context>
<name>@default</name>
<message>
<syntaxhighlight>File does not exist</syntaxhighlight>
<translation>Файла не існує</translation>
</message>
<message>
<syntaxhighlight>The file %1 could not be found. Please check this and try again.</syntaxhighlight>
<translation>Не вдалося знайти файл %1. Будь ласка, перевірте його наявність і спробуйте ще раз.</translation>
</message>
</context>
</TS>
Як бачите, файл записано у форматі XML, отже напряму редагувати такі файли незручно. Бібліотека має власний інструмент для перекладу таких файлів — Linguist.
Компіляція ред.
Після завершення перекладу файл перетворюється або вручну, або за допомогою команди:
lrelease -removeidentical -compress файл.ts -qm файл.qm
на файл, який власне і буде використано самою програмою (файл .qm). Втім виконувати цю операцію вручну навряд чи варто: з цим добре впорається і сам Linguist. Цей файл скрипт встановлення копіює до теки /usr/share/назва_програми/translations (можливі варіації). Отже для бойової перевірки перекладу слід використовувати саме подібну схему.
Формати для перекладу довідки ред.
Файли документації у форматі Docbook (XML) ред.
docbook XML — дуже поширений формат структурного оформлення документів, використовується у LDP, для довідки дистрибутивів (Fedora, Ubuntu), GNOME, KDE та безлічі інших програм. Подібні файли попередньо перетворюються на файли PO розробниками дистрибутивів. Якщо ж цього не зроблено, їх можна перекладати за допомогою xml2po, що є складовою gnome-doc-utils і kdesdk-po2xml.
Перетворення кількох документів docbook XML на POT-шаблон
xml2po -o book.pot chapter1.xml chapter2.xml
- новий переклад
- cp book.pot uk.po
- оновлення старого перекладу відносно нового шаблону
- msgmerge -o uk.po uk.po book.pot
Після перекладу файлу uk.po:
xml2po -p uk.po chapter1.xml > chapter1.uk.xml
xml2po -p uk.po chapter2.xml > chapter2.uk.xml
Зауваження. Не забудьте перевірити синтаксис отриманих docbook командою
checkXML chapter1.uk.xml
Перетворити створений підручник DocBook (побіжно перевіривши його на коректність) на сторінки HTML можна командою
meinproc4 chapter1.uk.xml
Файли XLIFF ред.
Цей тип файлу створено перекладу серйозної документації. Якщо за типової схеми перекладу вільних програм переклад відбувається за схемою
Переклад → Перекладач → Координатор → Сховище коду програми
то з перекладом XLIFF все набагато складніше:
Переклад → Перекладач → Рецензент → Підтверджувач → Координатор → Сховище коду програми → Нові рядки для перекладу → Перекладач...
з можливістю повернення на попередній етап на кожному з кроків. Якщо Ви надумаєте заробити грошей перекладом, ймовірно вам доведеться працювати з цим форматом.