Засади перекладу програмного забезпечення
Як і в будь-якому іншому перекладі, у перекладі повідомлень, написів, позначок (далі — рядків) у комп’ютерних програмах ми маємо кілька важливих чинників, що формують тон перекладу і впливають на його якість. Деякі з них, на перший погляд — банальні й очевидні, проте навіть очевидні речі часом можуть «вислизнути» із свідомості і спричинити плутанину. Тому й їх варто розглянути.
Процес перекладу
Ми розпочнемо із одного простого запитання. Відповідь на нього справді може здатись очевидною, але нам все ж потрібно її сформулювати, щоб можна було на неї опиратись, шукаючи відповіді на складніші запитання.
Місія перекладача програми
Отож, яку ціль ми маємо перед собою, перекладаючи інтерфейс програми? Варіантів може бути кілька. Нам потрібно знайти ту мотивацію, яка дасть ключ до якісного перекладу. Отже, ми хочемо перекласти програму так, щоб зміст рядків мовою перекладу найточніше втілював суть дії, об’єкта, ситуації, яку описує ориганальний рядок; ми хочемо, щоб для користувача програма виглядала так, наче вона й не була перекладена, а написана відразу із використанням мови, яку він бачить. Ідеалом для нас є програма, котра «думає» українською, а не лише «говорить» нею; це означає, що ми, при перекладі, стараємось зрозуміти, що має на увазі автор, і вкладаємо цю думку в наш, український рядок.
Ясна річ, це звучить очевидно. І це — добре. Але нам все ж потрібно загострити на цьому увагу, оскільки ця позиція пов’язана із дуже суттєвими моментами при перекладі, насамперед із трактуванням слова.
Трактування слова
Звернімось до конкретного прикладу. Ось рядок:
debug=#,-d Set to # or increment misc debug level
Це — фрагмент виводу команди wodim -help — програми запису CD- та DVD-дисків.
При перекладі цього повідомлення ми можемо піти двома кардинально відмінними шляхами. Результатом першого би було
debug=№,-d Призначити мішаний рівень налагодження №
Ми зробили просто — переклали кожне слово із максимально можливою точністю, і вклали їх у речення. Та чи передало воно основну думку, вкладену в оригінальне повідомлення? На жаль, ні. Саме тому нам потрібно застосувати інший підхід. Ось, що ми отримаємо в такому разі:
debug=№,-d Підняти об’єм виводу внутрішньої діагностичної інформації wodim до рівня №
Щоб з’ясувати справжнє значення рядка оригіналу, нам довелося скористатися man-підручником wodim, розібратися в контексті, а саме — в значенні близьких за функцією опцій -verbose, -Verbose та kdebug=, і лише після цього ми знаємо, як саме записати значення цієї опції українською.
Без сумніву, лише другий варіант перекладу має в собі сенс. Лише такий спосіб перекладу, тобто переклад змісту цілої фрази, разом із контекстом і, при необхідності із залученням додаткової інформації можна назвати якісним. Переклад окремих слів, наскільки б він не був ретельним і точним, часто може навіть близько не втілити самого значення тої чи іншої фрази.
Отож, слова трактуймо як частини, що утворюють ціле, і лише зміст цього цілого ми передаємо новими, власними словами.
Трактування мови
Хоча, не зовсім власними. Пишучи те чи інше повідомлення, ми не бачимо свого читача, тобто користувача програми. А ним може бути будь-хто. Саме тому ми повинні користуватись сучасною літературною українською мовою, і не вдаватись до діалектизмів чи використання сленгу.
Спірним питанням є правила правопису. Сьогодні існує щонайменше два погляди на цю проблему. Одні вважають, що ми повинні дотримуватись чинного правопису, тому що він є офіційно затверджений Верховною Радою України. Інші схильні відстоювати правопис 1999 року та його варіанти, і не чекати на його затвердження Верховною Радою. Чи має право на існування українська локалізація програми, у якій використано офіційно ще не прийнятий правопис, поки що залишається відкритим питанням.
Обговорення тут: http://linux.org.ua/cgi-bin/yabb/YaBB.pl?num=1295004245
Інші ж схильні перекладати інтуїтивно, і не задумуються, котрим правописом користуватися. Саме цей третій варіант є найбільш небезпечним — формуючи написання слів інтуїтивно, ми ризикуємо по-різному написати одне й те ж слово в різних місцях, і потім доведеться виправляти. Крім того, це веде до плутанини і неузгодженості між мовою різних програм, бо найчастіше стосується не тільки правил правопису, а й решти мовних аспектів локалізації.
В будь-якому випадку варто ознайомитися із тим, які способи написання ті чи інші джерела відстоюють, і як їх аргументують. Деякі посилання можна знайти в розділі ?Корисна література.
Мабуть, першим і найбільш важливим таким пунктом є Словник УМІФ (який, зокрема, надає таблиці відмінювання) та E2U.
Цілісність і послідовність
Які б стильові норми і принципи ми не обрали, ми повинні дотримуватись їх хоча б в рамках одного перекладу — однієї програми/пакунка. Звичайно, стильова єдність є величезним плюсом, якщо її дотримуватись в рамках всіх дотичних програм. Насамперед це стосуватиметься термінології. Як і правопис, українська технічна термінологія перебуває у досить нестабільному, і, на додачу, слаборозвиненому стані. Тому будьте готові взяти участь в обговоренні та узгодженні того чи іншого терміна. Детальніше про це трохи згодом.
Основні принципи перекладу
Пропоную підсумувати те, що ми розглянули. Отже, перекладаючи, ми повинні:
- Точно і зрозуміло відтворити засобами української мови те, що повинен повідомити той чи інший рядок у програмі;
- Користуватись сучасною літературною українською мовою;
- Дотриматись єдності стилю мови там, де є структурна єдність у вихідному матеріалі;
- Використовувати усталену термінологію, стиль, технічні стандарти як загальні, так і для кожної підгрупи проектів.