Локалізація програмних засобів/Мовні принципи локалізації/Головні принципи локалізації

Матеріал з Вікіпідручника
Перейти до навігації Перейти до пошуку

Засади перекладу програмного забезпечення[ред.]

Як і в будь-якому іншому перекладі, у перекладі повідомлень, написів, позначок (далі — рядків) у комп’ютерних програмах ми маємо кілька важливих чинників, що формують тон перекладу і впливають на його якість. Деякі з них, на перший погляд — банальні й очевидні, проте навіть очевидні речі часом можуть «вислизнути» із свідомості і спричинити плутанину. Тому й їх варто розглянути.

Процес перекладу[ред.]

Ми розпочнемо із одного простого запитання. Відповідь на нього справді може здатись очевидною, але нам все ж потрібно її сформулювати, щоб можна було на неї опиратись, шукаючи відповіді на складніші запитання.

Місія перекладача програми[ред.]

Отож, яку ціль ми маємо перед собою, перекладаючи інтерфейс програми? Варіантів може бути кілька. Нам потрібно знайти ту мотивацію, яка дасть ключ до якісного перекладу. Отже, ми хочемо перекласти програму так, щоб зміст рядків мовою перекладу найточніше втілював суть дії, об’єкта, ситуації, яку описує оригінальний рядок; ми хочемо, щоб для користувача програма виглядала так, наче вона й не була перекладена, а написана відразу мовою, яку він бачить. Ідеалом для нас є програма, яка «думає» українською, а не лише «говорить» нею; це означає, що ми, при перекладі, стараємось зрозуміти, що має на увазі автор, і вкладаємо цю думку в наш, український рядок.

Ясна річ, це звучить очевидно. І це — добре. Але нам все ж потрібно загострити на цьому увагу, оскільки ця позиція пов’язана із дуже суттєвими моментами при перекладі, насамперед із трактуванням слова.

Трактування слова[ред.]

Звернімось до конкретного прикладу. Ось рядок:

        debug=#,-d      Set to # or increment misc debug level

Це — фрагмент виводу команди wodim -help — програми запису CD- та DVD-дисків.

При перекладі цього повідомлення ми можемо піти двома кардинально відмінними шляхами. Результатом першого би було

        debug=№,-d      Призначити мішаний рівень налагодження №

Ми зробили просто — переклали кожне слово із максимально можливою точністю, і вклали їх у речення. Та чи передало воно основну думку, вкладену в оригінальне повідомлення? На жаль, ні. Саме тому нам потрібно застосувати інший підхід. Ось, що ми отримаємо в такому разі:

        debug=№,-d      Підняти обсяг виводу внутрішньої діагностичної інформації до рівня №

Щоб з’ясувати справжнє значення рядка оригіналу, нам довелося скористатися man-підручником wodim, розібратися в контексті, а саме — в значенні близьких за функцією опцій -verbose, -Verbose та kdebug=, і лише після цього ми знаємо, як саме записати значення цієї опції українською.

Без сумніву, лише другий варіант перекладу має в собі сенс. Лише такий спосіб перекладу, тобто переклад змісту цілої фрази, разом із контекстом і, при необхідності із залученням додаткової інформації можна назвати якісним. Переклад окремих слів, наскільки б він не був ретельним і точним, часто може навіть близько не втілити самого значення тої чи іншої фрази.

Отож, слова трактуймо як частини, що утворюють ціле, і лише зміст цього цілого ми передаємо новими, власними словами.

Трактування мови[ред.]

Хоча, не зовсім власними. Пишучи те чи інше повідомлення, ми не бачимо свого читача, тобто користувача програми. А ним може бути будь-хто. Саме тому ми повинні користуватись сучасною літературною українською мовою, і не вдаватись до діалектизмів чи використання сленгу.

Дехто схильний перекладати інтуїтивно, і не задумуватися, яким правописом користуватися (наприклад, чи писати якесь слово через «ґ», чи «г»). Такий спосіб не є найкращим — формуючи написання слів інтуїтивно, ми ризикуємо по-різному написати одне й те ж слово в різних місцях, і потім доведеться виправляти. Крім того, це веде до плутанини і неузгодженості між мовою різних програм, бо найчастіше стосується не тільки правил правопису, а й решти мовних аспектів локалізації.

Мабуть, авторитетнішим пунктом для перевірки написання того чи іншого слова є Орфографічний словник Українського мовно-інформаційного фонду (який, зокрема, надає таблиці відмінювання); менш авторитетними, але також корисними є Англійсько-українські словники сайту e2u.org.ua.

Цілісність і послідовність[ред.]

Які б стильові норми і принципи ми не обрали, ми повинні дотримуватись їх хоча б в рамках одного перекладу — однієї програми/пакунка. Звичайно, стильова єдність є величезним плюсом, якщо її дотримуватись в рамках всіх дотичних програм. Насамперед це стосуватиметься термінології. Як і правопис, українська технічна термінологія перебуває у досить нестабільному, і, на додачу, слаборозвиненому стані. Тому будьте готові взяти участь в обговоренні та узгодженні того чи іншого терміна. Детальніше про це трохи згодом.

Основні принципи перекладу[ред.]

Пропоную підсумувати те, що ми розглянули. Отже, перекладаючи, ми повинні:

  1. Точно і зрозуміло відтворити засобами української мови те, що повинен повідомити той чи інший рядок у програмі;
  2. Користуватись сучасною літературною українською мовою;
  3. Дотриматись єдності стилю мови там, де є структурна єдність у вихідному матеріалі;
  4. Використовувати усталену термінологію, стиль, технічні стандарти як загальні, так і для кожної підгрупи проектів.

Примітки[ред.]