Переклад технічної документації часто сприймають як фінальний етап: виробник уже підготував інструкцію, креслення, специфікації, таблиці, а тепер ці матеріали потрібно просто перекласти іншою мовою. На практиці саме слово «просто» тут створює найбільше проблем.
Технічний документ — це не звичайний текст. Його читають не заради інформації як такої, а щоб виконати конкретну дію: зібрати обладнання, підключити систему, провести технічне обслуговування, знайти потрібну деталь, перевірити помилку, виконати процедуру безпеки. Тому кожен термін, позначення, посилання на рисунок чи назва кнопки мають працювати не окремо, а як частина однієї системи.
Саме через це якісний технічний переклад починається ще до першого перекладеного речення. Потрібно зрозуміти, які матеріали є вихідними, чи існують попередні переклади, як оформлені схеми, у якому форматі збережені креслення, чи є корпоративна термінологія, хто буде користуватися документацією і яким має бути фінальний файл.
Для виробничої або імпортної компанії це не формальність. Від підготовки залежить, наскільки швидко пройде переклад, скільки буде уточнень, чи доведеться переробляти верстку і, головне, — чи буде готовий документ справді придатний для роботи.
Чому технічний переклад починається ще до роботи перекладача
Інструкція з експлуатації, сервісний мануал, паспорт обладнання або комплект монтажної документації майже ніколи не складаються лише з абзаців тексту. Зазвичай там є таблиці, креслення, специфікації, формули, коди деталей, попереджувальні блоки, примітки, посилання на рисунки та внутрішня нумерація. Часто одна й та сама назва зустрічається одразу в кількох місцях: у тексті, на схемі, у переліку запасних частин і в інтерфейсі самого обладнання.
Через це переклад не можна виконувати як сукупність незалежних фраз.
Уявімо інструкцію до промислового компресора. У тексті згадується pressure relief valve; у специфікації цей елемент має окремий артикул, а на схемі він позначений як V12. Якщо в основному тексті він стане «запобіжним клапаном», у таблиці — «клапаном скидання тиску», а на кресленні залишиться англійською, документ формально не буде неправильним. Проте користувачу доведеться щоразу перевіряти, чи йдеться про один і той самий компонент.
У документації на кілька сотень сторінок такі дрібні відмінності накопичуються. І в якийсь момент проблема вже не в стилі, а в тому, що читачеві складніше працювати з документом.
Ще один важливий фактор — призначення матеріалу. Інструкція для кінцевого користувача має бути зрозумілою та практичною. Сервісний мануал — точний і професійний. Монтажна документація повинна максимально чітко відповідати схемам і позначенням. Каталог обладнання, навпаки, може поєднувати технічну точність із більш маркетинговою подачею.
Тому перед початком роботи важливо визначити, хто буде читати переклад і для чого.
Не менш важливий формат вихідних матеріалів. Word із редагованим текстом, PDF із текстовим шаром, сканований PDF і DWG-файл можуть показувати той самий зміст, але з точки зору роботи це різні завдання. У першому випадку текст легко редагувати. У другому — частково. У третьому спочатку потрібно відновити зміст. У четвертому перекладі може бути інтегрований безпосередньо в креслення.
Саме тому правильний старт — це короткий аудит документації. Він дає змогу побачити весь обсяг робіт до того, як проєкт уже «пішов у переклад».
Які матеріали варто передати разом із документом
Одна з найпоширеніших ситуацій — замовник надсилає один PDF і очікує, що цього достатньо. Для невеликої інструкції це може спрацювати. Для складного обладнання — не завжди.
Перекладач бачить слова, але не завжди бачить продукт.
Наприклад, назва вузла може мати кілька коректних відповідників, і лише каталог виробника або фото обладнання показує, про що саме йдеться. Або скорочення, яке здається стандартним, насправді є внутрішнім кодом конкретної компанії. Без контексту перекладач змушений витрачати час на пошук або робити припущення.
Тому разом з основним документом корисно передати будь-які матеріали, які допомагають зрозуміти продукт: каталоги, специфікації, datasheets, попередні інструкції, креслення, технічні презентації, посилання на сайт виробника, відео роботи обладнання.
Особливу цінність мають старі переклади.
Навіть якщо вони неідеальні, вони показують термінологію, до якої компанія вже звикла. Наприклад, сервісна служба кілька років використовує певну назву вузла. Якщо новий переклад раптом вводить інший термін — технічно правильний, але незнайомий персоналу — це може створити більше проблем, ніж користі.
Тому попередні матеріали варто розглядати не як «старі файли», а як термінологічну історію компанії.
Ще один важливий ресурс — документація на суміжне обладнання. Виробник може використовувати однакові терміни в різних моделях, і це допомагає побачити систему назв, а не окреме слово в одному реченні.
Для обладнання з дисплеями або ПЗ корисно передавати скриншоти інтерфейсу. Якщо інструкція каже «натисніть кнопку Start Cycle», але на реальному екрані користувач бачить саме START CYCLE, переклад має це враховувати. Інакше український текст може бути правильним, але відірваним від реальної роботи оператора.
Глосарій як робочий інструмент, а не формальність
У технічному перекладі далеко не всі проблеми пов’язані зі складними термінами. Частіше складність виникає тоді, коли один термін можна перекласти кількома способами.
Наприклад, housing залежно від конструкції може бути корпусом, кожухом або оболонкою. Drive — привід, приводний механізм або модуль приводу. Seal — ущільненням, манжетою, сальником або пломбою.
Якщо кожен термін розглядати лише в конкретній реченні, окремі рішення можуть бути правильними. Але технічний документ має ще одну вимогу — послідовність.
Саме для цього потрібен глосарій.
По суті, це погоджена база термінів, у якій фіксуються ключові назви деталей, вузлів, процесів, режимів, матеріалів, команд інтерфейсу, скорочення та службові позначення.
Глосарій особливо цінний у великих проєктах. Якщо над перекладом працюють кілька фахівців, без спільної бази кожен може вибрати свій коректний варіант. Після цього редактор витрачає години на вирівнювання термінології.
Якщо правила узгоджені на старті, значна частина таких проблем просто не виникає.
У хорошому глосарії важливі не лише «переклади слів». У ньому можуть бути примітки: не перекладати назву продукту; залишати код без змін; використовувати певну назву лише для однієї моделі; зберігати англійську назву інтерфейсу поряд з українською.
Тобто це вже не просто словник, а набір робочих рішень для конкретного проєкту.
Що робити, якщо глосарію немає
Відсутність готової термінологічної бази не повинна зупиняти проєкт. Насправді в багатьох компаніях окремого глосарію взагалі немає.
Терміни можуть бути розкидані по десятках файлів: частина — в технічних каталогах, частина — у старих інструкціях, частина — в Excel-таблицях, а частина існує лише в усній мові інженерів.
У такій ситуації глосарій можна створити вже під час першого перекладу.
Перекладач або редактор виділяє терміни, які часто повторюються або можуть бути неоднозначними, пропонує базові відповідники та формує список питань. Замовник не мусить перевіряти сотні сторінок. Достатньо погодити кілька десятків ключових рішень.
Це важлива різниця.
Замість запиту «перевірте переклад» технічний спеціаліст отримує конкретне питання: який варіант назви цього вузла використовується у вашій компанії? Чи перекладається ця абревіатура? Чи залишаємо англійську команду на екрані?
Такі питання вирішуються набагато швидше.
Після першого проєкту база вже існує. Наступна інструкція, каталог або сервісний мануал не починається з нуля. Частина рішень автоматично переноситься далі.
Для імпортера, який регулярно працює з одним брендом, це може мати відчутний економічний ефект: менше погоджень, менше редакторських виправлень, швидший запуск наступних проєктів.
AutoCAD, PDF і креслення: формат файлу має значення
Для технічної документації формат іноді важливіший за кількість сторінок.
Десять складних креслень у вигляді сканів можуть потребувати більше часу, ніж сто сторінок інструкції в Word. Причина проста: текст потрібно не лише перекласти, а й знайти, відновити, прив’язати до графічних елементів і правильно повернути в документ.
Найзручніший варіант — вихідні файли, відредаговані в редакторі, наприклад, DWG або DXF. У них текстові елементи можна змінювати безпосередньо у структурі креслення, зберігаючи виноски, позиції та прив’язки.
З PDF ситуація складніша.
Якщо файл експортований з AutoCAD або іншої програми й містить текстовий шар, з ним можна працювати досить зручно. Якщо це скан, написи стають частиною зображення.
Для великих комплектів це вже суттєво впливає на вартість і строки.
Тому перед стартом варто перевірити, чи є у виробника вихідні файли. Іноді імпортер отримує лише PDF, але DWG можна запросити окремо. Один лист виробнику на початку може зекономити багато ручної роботи надалі.
Окреме питання — що саме перекладати всередині креслення. Не всі написи потребують локалізації.
Коди деталей, номери позицій, позначення електричних компонентів або артикули часто мають залишатися без змін. Назви вузлів, примітки, попередження та інструктивні підписи, навпаки, можуть потребувати перекладу.
Тому доцільно спочатку розділити елементи на три групи: перекладати, залишати без змін, подавати двома мовами.
Це значно надійніше, ніж механічно перекладати все, що схоже на текст.
Чому текст, таблиці та схеми потрібно перевіряти разом
Технічна документація працює через зв’язки.
Текст посилається на рисунок. Рисунок — на позицію. Позиція — на специфікацію. У специфікації є код деталі. Користувач за цим кодом замовляє запасну частину.
Якщо хоча б один із цих зв’язків порушити, помилка може проявитися далеко за межами самого перекладу.
Наприклад, у тексті вказано: «Встановіть фільтр на поз. 18». Після переверстки нумерація на рисунку змінилася або підпис випадково перемістився. Речення перекладене правильно, але інструкція вже веде користувача не до потрібного компонента.
Тому фінальна перевірка має охоплювати не лише мову, а й внутрішню логіку документа.
Особливо це стосується багатосторінкових інструкцій, де є десятки перехресних посилань. Після перекладу змінюється обсяг тексту, сторінки можуть зміщуватися, таблиці розширюються. Якщо посилання прив’язані вручну, вони потребують окремої перевірки.
Ще один нюанс — інтерфейс обладнання.
Не завжди потрібно перекладати команду так, щоб оригінал повністю зник. Якщо користувач фізично бачить на кнопці EMERGENCY STOP, а в інструкції читає лише «Аварійна зупинка», він має додатково здогадатися, що це те саме.
У таких випадках краще формулювати інструкцію так, щоб вона допомагала орієнтуватися в реальному обладнанні.
Верстка — це частина технічного перекладу
Часто замовник оцінює обсяг проєкту за кількістю слів. Для технічної документації цього недостатньо.
Якщо файл має складну структуру, частина роботи починається вже після перекладу.
Український текст може бути довшим за англійський. Через це підписи не поміщаються у блоки, таблиці розширюються, попередження переходять на наступну сторінку, а рисунки зміщуються.
У документації на кілька сторінок це легко виправити вручну. У великому мануалі такі зміни можуть повторюватися сотні разів.
Тому формат кінцевого документа потрібно погоджувати ще до старту.
Якщо потрібен лише переклад тексту для внутрішнього використання, немає сенсу витрачати час на повне відтворення дизайну. Якщо інструкція передаватиметься клієнтам або монтажникам, навпаки, структура й візуальна відповідність можуть бути принциповими.
Для частини компаній оптимальним рішенням буде Word. Для інших — фінальний PDF. Якщо документація регулярно оновлюється, доцільно зберігати відредаговану версію, щоб наступні зміни не довелося вносити знову.
Це варто обговорити заздалегідь, а не після завершення перекладу.
Хто має відповідати на технічні питання
Навіть добре організований проєкт не виключає уточнень.
Особливо якщо обладнання вузькоспеціалізоване або компанія використовує власну термінологію.
Найкраще, коли з боку замовника є одна людина, до якої можна звернутися з технічними питаннями. Це не обов’язково має бути керівник або людина, яка знає іноземну мову. Важливіше, щоб вона добре розуміла продукт.
Це може бути інженер, технолог або сервісний спеціаліст.
При цьому ефективна схема не передбачає, що ця людина перечитує весь переклад.
Завдання бюро — самостійно опрацювати документацію і сформулювати лише ті питання, де без знання внутрішнього контексту не обійтися.
Добре працює формат короткої таблиці із сумнівними термінами, фрагментом контексту та запропонованим варіантом. Замовник швидко підтверджує рішення, після чого воно фіксується в глосарії.
Такий підхід значно кращий за нескінченне листування щодо одного терміна.
Як передати великий комплект документації без хаосу
Окрема проблема великих проєктів — не сам переклад, а управління файлами.
Виробничі компанії часто мають кілька версій однієї інструкції, окремі креслення, доповнення до специфікації, нові сторінки, виправлені схеми. Якщо все це надходить у різні дні через різні канали, ризик переплутати версії зростає дуже швидко.
Тому бажано передавати матеріали структуровано.
Наприклад, окрема папка для вихідної документації, окрема — для референсів, окрема — для креслень. Якщо є кілька редакцій файлу, бажано чітко позначити актуальну.
Для великих проєктів також корисно визначити пріоритети.
Не обов’язково чекати перекладу всіх 800 сторінок, якщо монтажна бригада через тиждень потребує лише 70. Проєкт можна розділити на етапи: спочатку — монтажна документація, потім — операторська, після цього — сервісна.
Це дає бізнесу можливість користуватися результатом ще до завершення всього обсягу.
Чекліст перед передачею документації
Перед стартом варто перевірити кілька речей: які саме файли потрібно перекласти, чи є редаговані вихідники, чи потрібно працювати зі схемами та графікою, чи існують старі переклади, у якому форматі потрібен результат, хто буде користуватися документом і хто з боку компанії зможе відповісти на технічні питання.
Також бажано одразу повідомити про критичні строки. Якщо частина матеріалів потрібна раніше, краще врахувати це ще під час планування.
Якщо ж незрозуміло, які саме файли варто передавати і чи достатньо PDF, не потрібно самостійно перебудовувати весь комплект.
Матеріали можна спочатку показати фахівцям.
У Центрі перекладів СТАТУС КО ми можемо попередньо оцінити структуру технічної документації, формат файлів, складність схем, необхідність роботи з AutoCAD, версткою та термінологією. Після цього можна визначити оптимальний порядок перекладу, формат результату та приблизний обсяг додаткових робіт.
Для виробничої або імпортної компанії це означає прогнозований процес ще до старту.
І, мабуть, це головна різниця між просто перекладеним файлом і професійно підготовленою технічною документацією: у другому випадку документ не лише добре звучить іншою мовою, а й залишається робочим інструментом для людей, які ним користуватимуться.
