Підготовка файлів до перекладу: що перевірити до передавання¶

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

Підготувати файл до перекладу - означає перевірити вихідний текст, його структуру й версію, додати потрібний контекст і зібрати супровідні матеріали. Мета не в тому, щоб документ просто гарно виглядав. Перекладач має розуміти, що саме перекладати, як трактувати терміни та які елементи залишити без змін.

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

Далі розберемо Word-файли, програмні рядки й довідкові матеріали та складемо список того, що перевірити перед передаванням. Якщо найбільше хвилює форматування тегів у CAT-системі, відкрийте окремий матеріал про фільтри файлів для CAT-систем. А для фінальної перевірки верстки стане в пригоді чекліст контролю форматування перекладених файлів.

Що означає підготувати файл до перекладу¶

Файл готовий до перекладу, коли текст затверджено, структура зрозуміла, версію визначено, а контексту достатньо, щоб правильно тлумачити зміст. Те, що документ відкривається у Word або збережений у прийнятному форматі, ще не означає, що його вже можна передавати.

Думайте про передавання як про пакет, а не просто вкладення до листа. До нього можуть увійти:

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

Кожен матеріал має допомагати ухвалити конкретне рішення. Старий глосарій із суперечливими варіантами не додає ясності - він створює ще одне питання. Неактуальний переклад опису продукту може заплутати сильніше, ніж відсутність попередньої версії.

Чому якість джерела впливає на результат¶

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

Microsoft радить перевіряти орфографію та граматику перед передаванням рядків. У настановах Microsoft щодо контекстних метаданих сказано, що така перевірка зменшує кількість запитань і повторної роботи. Там само радять послідовно вживати терміни й уникати двозначних формулювань.

Уявіть кнопку з англійським словом “light”. Йдеться про світло, невелику вагу чи світлий колір? Сам короткий рядок відповіді не дає. Примітка «назва світлої теми інтерфейсу» зніме питання, а ще краще - одразу назвати потрібне поняття у вихідному тексті.

Схожа пастка - ланцюжок іменників. Для автора стисла фраза може бути очевидною, а читачеві неясно, як слова пов’язані між собою. Microsoft радить уточнювати значення таких конструкцій у вихідному тексті, додаючи потрібні прийменники чи інші слова. Чітке речення залишає перекладачеві більше свободи передати думку природно.

Коли варто починати підготовку¶

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

Такий порядок особливо корисний для документації, інструкцій, інтерфейсів і матеріалів, які часто оновлюються. Microsoft зазначає: правки після повного перекладу можуть додати роботи, адже навіть одне змінене слово іноді змушує переробити речення, щоб воно звучало природно цільовою мовою. Настанова Microsoft щодо локалізації документації пояснює, що CAT-інструменти й пам’ять перекладів допомагають узгоджувати локалізований вміст зі змінами у вихідному тексті. Та вони не замінюють контролю версій.

Як пише Microsoft Learn у матеріалі про локалізацію документації:

“At a bare minimum, this means using styles in a Word document instead of formatting everything manually.”

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

Як підготувати документ Word і не загубити важливий вміст¶

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

Microsoft радить оформлювати заголовки та інші елементи стилями Word, а не задавати форматування вручну. У настанові з локалізації документації також згадано Markdown і DITA XML як структурованіші альтернативи для документації. Який формат обрати - залежить від процесу вашої команди, але суть одна: структуру треба задати, а не змушувати людей вгадувати її за зовнішнім виглядом.

Спочатку визначте фінальну версію¶

Файл manual_final_final2.docx не підкаже, чи справді його затвердили. Визначте один документ як джерело правди, зазначте його версію в супровідному повідомленні й передавайте всі зміни узгодженим каналом.

Ось простий порядок:

1. Автор завершує зміст і підтверджує, що файл готовий до перекладу.
2. Координатор перевіряє назву, формат і відповідність погодженій версії.
3. Команда фіксує зміни, які з’явилися після початку роботи.
4. Перекладач отримує оновлений файл і чітке пояснення, що саме змінилося.

Не використовуйте листування як єдине сховище версій. Вкладення з різних ланцюжків листів легко сплутати, особливо якщо назва файла нечітка або дата збереження не збігається з датою затвердження. Зберігайте документ там, де команда може побачити, хто за нього відповідає і чи він актуальний.

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

Розберіться з виправленнями й коментарями¶

Не передавайте файл, просто сховавши позначені виправлення. У Word режим No Markup лише тимчасово змінює їхнє відображення: після повторного відкриття виправлення з’являться знову. Microsoft пояснює це в інструкції щодо прийняття або відхилення виправлень.

Як пише Microsoft Support у цій інструкції:

“Choosing the No Markup view only temporarily hides changes. They will be visible again the next time someone opens the document.”

Перед передаванням прийміть або відхиліть кожну правку. Невирішене виправлення залишає перекладачеві запитання: брати старий варіант, новий чи обидва? Якщо власник тексту ще не вирішив, перекладач не має підстав обирати замість нього.

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

Перевірте прихований текст і властивості документа¶

У Word можуть залишитися елементи, яких не видно під час звичайного читання: прихований текст, старі коментарі, імена у властивостях та інші дані. Microsoft радить перед поширенням файла запускати Document Inspector, щоб перевірити такі елементи. Інформацію про перевірку документа наведено в довідці Microsoft Support щодо виправлень у Word.

Не видаляйте все знайдене автоматично. Спершу з’ясуйте, чи має цей елемент залишитися у фінальному файлі. Текст у колонтитулі, наприклад, може потребувати перекладу, а службова примітка - ні. Важливо, щоб рішення ухвалила команда: перекладач може побачити текст, який автор не вважав частиною завдання.

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

Перевірте структуру, не знищуючи форматування¶

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

Не видаляйте всі стилі масово й не копіюйте документ у звичайний текстовий редактор «для спрощення». Так можна втратити відступи, структуру таблиць, нумерацію й зв’язки між заголовками. Якщо верстка складна, заздалегідь узгодьте з перекладачем чи координатором, що має залишитися без змін, а що перевірятимуть після перекладу.

Проблема часто ховається за охайним виглядом документа. Два рядки можуть виглядати однаково, хоча один має стиль заголовка, а другий - лише ручне форматування. Стилі повідомляють програмам і людям, яку роль виконує текст. Тому структуроване оформлення стане в пригоді не лише для перекладу, а й для подальшого догляду за документом.

Як зібрати контекст і довідкові матеріали для перекладача¶

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

Склад пакета залежить від проєкту, але перевірте, чи потрібні такі матеріали:

Матеріал	Що пояснює	Що перевірити перед передаванням
Глосарій	Погоджені терміни й назви	Чи немає застарілих або суперечливих варіантів
Стильовий посібник	Тон, звертання, написання й формат	Чи підходять правила саме цьому продукту й аудиторії
Попередній переклад	Раніше затверджені рішення	Чи актуальна версія і чи можна її використовувати
Контекстні примітки	Значення конкретних фрагментів	Чи пояснено місце, функцію та обмеження
Інструкція до завдання	Мету, аудиторію, формат результату	Чи зрозумілі очікувані файли й відповідальні за погодження

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

Глосарій має містити рішення, а не припущення¶

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

Уточніть, чи треба перекладати назви бренду, кнопок і функцій, чи вони мають залишитися мовою оригіналу. Позначте варіанти, яких не можна використовувати. Не розраховуйте, що перекладач знайде заборону в старому листуванні.

Послідовність термінів важлива для документації та інтерфейсів, де та сама назва з’являється в різних розділах. Якщо термін змінюється після початку перекладу, повідомте про це й перелічіть місця, яких торкнулася зміна. Не просіть замінити варіант скрізь, не перевіривши контекст: однакова форма у вихідному тексті може виконувати різні функції.

Стильовий посібник має відповідати реальному завданню¶

У стильовому посібнику можна зафіксувати звертання до читача, рівень формальності, написання дат, одиниць вимірювання, назв і заголовків. Для невеликого завдання окремий документ не обов’язковий - вистачить короткої примітки. Для регулярної роботи зручніше мати один набір правил і людину, яка відповідає за його оновлення.

Не давайте суперечливих вказівок на кшталт «збережіть точну структуру» і водночас «вільно перепишіть кожен заголовок». Якщо йдеться про верстку, зазначте, які елементи треба зберегти. Якщо про тон - наведіть приклад бажаного голосу, але не вимагайте копіювати вихідне речення слово в слово.

Передавайте посібник, який підходить до аудиторії та типу тексту. Правила для маркетингової сторінки можуть не працювати для інструкції з безпеки. Якщо для юридичних, технічних або користувацьких текстів діють окремі вимоги, вкажіть їх у пакеті й поясніть, які правила мають перевагу, якщо вони суперечать одне одному.

Контекстна примітка має пояснювати, де й навіщо з’являється текст¶

Контекст - це не просто ще одне формулювання того самого слова. Він пояснює, де з’являється рядок, що робить користувач, до чого належить назва і за яких умов показується повідомлення. Microsoft радить додавати коментарі, які пояснюють місце й функцію рядка, зокрема чи є він іменником або дієсловом, а також умови показу. Настанова Microsoft про контекстні метадані нагадує: метадані не замінюють чіткого вихідного тексту.

Ось корисна примітка: «Текст на кнопці, яка запускає завантаження звіту. Це дія, а не назва файлу». Вона відповідає на практичне запитання. А «перекласти коротко» не пояснює ані функції, ані обмеження, ані потрібного змісту.

Як пише Microsoft Learn у настанові про контекстні метадані:

“You should verify spelling and grammar before sending strings to translators.”

Ця порада стосується не лише кнопок і коротких повідомлень. Перевірте джерело перед передаванням, щоб неоднозначність не перетворилася на запитання вже під час перекладу.

Не ставте коментар замість зрозумілого тексту¶

Примітки дають додатковий контекст, але не мають виправляти неясне речення. Якщо автор знає, що мав на увазі, за можливості варто прямо сказати це у вихідному тексті. Коментар може пояснити роботу функції, але не повинен бути єдиним місцем, де заховано важливу частину змісту.

Перевірте неоднозначні слова, скорочення й короткі назви функцій. Уточніть, чи це назва, дія, категорія або частина повідомлення. Якщо значення змінної або терміна неочевидне, додайте приклад. Для документації прикріпіть фрагмент до й після неоднозначного речення, якщо сусідній контекст важливий.

Якщо у матеріалі є покажчик, індекс або сортування, пам’ятайте, що правила залежать від мови. Microsoft окремо зазначає: локалізовані індекси мають відповідати звичаям цільової мови. Тож не завжди правильно залишати порядок елементів таким, як у вихідній версії. Команда має вирішити, чи потрібно сортувати їх за правилами локалі.

Як підготувати програмні рядки, змінні й плейсхолдери¶

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

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

Передавайте повні рядки замість склеєних фрагментів¶

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

У настанові Microsoft щодо форматування повідомлень є така порада:

“With a few exceptions, memory isn’t the primary consideration when authoring resources. Best practice is to never concatenate strings.”

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

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

Пояснюйте кожен плейсхолдер¶

Назва змінної не обов’язково пояснює, що вона означає. count може бути кількістю файлів, людей, повідомлень або днів. Додайте коментар про кожну змінну й, коли це допоможе, наведіть приклад можливого значення.

У корисній примітці є:

• значення змінної;
• тип даних або поняття, яке вона представляє;
• приклад підстановки;
• вказівка, чи можна змінювати порядок плейсхолдерів;
• умови показу рядка, якщо вони впливають на його зміст.

Наприклад: «{userName} - ім’я користувача у привітанні. Приклад значення: Марія». Це пояснює більше, ніж сама назва змінної. Microsoft також радить розкривати значення змінних і наводити приклади: назви плейсхолдерів перекладачеві може бути замало.

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

Дозвольте змінювати порядок плейсхолдерів¶

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

Якщо програма не дозволяє переміщати змінні, скажіть про це прямо й перевірте, чи можна змінити шаблон. Жорстке обмеження може завадити скласти природне речення. Якщо переміщення дозволене, уточніть, що саме захищене: змінна має залишитися в рядку, але її місце може змінитися.

Якщо в повідомленні кілька плейсхолдерів, поясніть кожен окремо. Не покладайтеся на їхню позицію: перекладачеві потрібно розуміти кожне значення навіть після перебудови речення.

Додайте обмеження довжини та технічні правила¶

Якщо поле має обмеження довжини, напишіть про нього в примітці до рядка. Microsoft згадує обмеження довжини й заборонені символи серед вимог, які варто зазначати в контекстних коментарях. Не обмежуйтеся словами «зробити коротко»: поясніть, де з’являється текст і що саме обмежено технічно.

Також уточніть, чи можна використовувати певні символи, чи є в рядку код і чи генерує програму частину тексту. Розділіть технічну вимогу й стилістичне побажання. Навіть короткий переклад може не вміститися в інтерфейс, доки його не перевірять у продукті.

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

Перевірте поведінку множини й форматування повідомлень¶

Повідомлення з кількістю не завжди можна скласти з числа й незмінного слова. Мова може вимагати різних форм залежно від кількості, а порядок частин - відрізнятися. Передавайте повідомлення як цілу конструкцію з потрібними варіантами, а не як число, до якого вручну додають фрагмент тексту.

Уточніть, чи є в повідомленні іменник, дія, назва або змінна. Поясніть, що відбувається, якщо значення відсутнє, і чи з’являється текст у різних станах інтерфейсу. Так перекладач зможе врахувати і видимий рядок, і те, як його використовує програма.

Перед передаванням пройдіться по кожному ресурсу й перевірте: чи є повне речення, чи зрозуміла його функція, чи пояснені плейсхолдери та обмеження. Якщо відповіді немає, уточніть її до старту або позначте рядок для перевірки. Не маскуйте відсутність контексту коментарем «перекласти за контекстом».

Поширені помилки під час підготовки файлів¶

Найбільше клопоту створює не складний формат, а невизначеність, яку команда передає разом із файлом. Перевірте типові помилки до старту, а не чекайте, поки перекладач поставить запитання.

Надсилання не тієї версії¶

Найновіший за датою змінення файл не обов’язково затверджений. Автор міг відкрити його й зберегти, не отримавши погодження, тоді як старіший уже пройшов редакторську перевірку. Визначте, хто затверджує документ, і зазначте версію в повідомленні перекладачеві.

Якщо зміна з’явилася після початку роботи, не надсилайте нову копію під тією самою назвою без пояснень. Повідомте, що саме змінилося, і вирішіть, чи потрібно оновлювати переклад. Microsoft попереджає: навіть правка одного слова після завершення перекладу може змусити переробити речення. Саме тому контроль версій - частина підготовки, а не просто адміністративна звичка.

Приховування правок замість їх вирішення¶

Режим No Markup не видаляє виправлення. Передайте файл у такому стані - і перекладач може побачити їх після повторного відкриття або в іншій програмі. Microsoft розрізняє прийняття чи відхилення правок і тимчасове приховування: докладніше в довідці Microsoft Support.

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

Передавання коментарів без сортування¶

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

Перевірте також, чи не залишилися дані, які не можна передавати зовнішнім виконавцям. Microsoft радить користуватися Document Inspector, щоб шукати виправлення, коментарі, прихований текст, імена у властивостях та іншу інформацію перед поширенням файла. Інспектор допоможе знайти матеріал, але вирішувати, що видалити, має власник документа.

Занадто стислі або неоднозначні рядки¶

Короткий текст може мати кілька значень. Одиночне слово з ресурсного файла, кнопка чи заголовок іноді не пояснюють, яку роль виконують. Додайте контекст і водночас перевірте, чи можна зробити саме вихідне формулювання яснішим.

Прочитайте кожен рядок окремо. Якщо автор не може пояснити його без усного коментаря, перекладачеві також бракуватиме контексту. Для коротких елементів зазначте, де вони з’являються, що роблять і за яких умов використовуються.

Склеювання речень із кількох частин¶

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

Як пише Microsoft Learn у матеріалі про форматування повідомлень:

“Choosing the No Markup view only temporarily hides changes. They will be visible again the next time someone opens the document.”

Ця цитата стосується правок у Word, а не програмних фрагментів. Але висновок про дані теж практичний: не плутайте тимчасове відображення з остаточним станом. Для програмних рядків потрібне окреме технічне рішення - передавати цілі повідомлення й дозволяти потрібний граматичний порядок змінних.

Непомітна зміна макета між мовами¶

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

Для друкованого документа можуть знадобитися зміни сторінки під цільовий ринок. Microsoft порівнює паперові формати ISO 216, поширені в більшості країн, із дюймовими форматами Letter і Legal у США. Якщо результат призначений для друку, заздалегідь погодьте формат сторінки, відступи й відповідального за локалізацію верстки.

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

Надсилання довідки, яка суперечить сама собі¶

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

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

Фінальна перевірка перед передаванням¶

Передайте пакет після короткої перевірки не лише формату, а й змісту. Пройдіться за цими питаннями:

• Чи підтвердив власник, що це остаточна вихідна версія?
• Чи прийняті або відхилені всі виправлення?
• Чи перевірено коментарі, прихований текст і властивості Word?
• Чи збережено логічну структуру заголовків, списків і таблиць?
• Чи пояснено неоднозначні терміни, назви та короткі рядки?
• Чи актуальні глосарій, стильовий посібник і попередні переклади?
• Чи повні програмні рядки, а плейсхолдери й обмеження зрозумілі?
• Чи зазначено, які зображення, покажчики або елементи макета треба локалізувати?
• Чи відомо, кому ставити запитання і хто погоджує термінологічні рішення?

Якщо відповіді на якесь питання немає, призначте відповідального до початку роботи. Невизначеність не зникає після передавання - вона просто переходить до перекладача й повертається запитом, затримкою або повторним редагуванням.

FAQ¶

Як підготувати документ Word перед передаванням перекладачеві?¶

Затвердьте текст і версію, прийміть або відхиліть усі виправлення, перевірте коментарі й прихований текст, а заголовки оформіть стилями Word. Додайте актуальний глосарій, контекстні примітки та пояснення до елементів, які не можна змінювати.

Чи потрібно приймати виправлення перед перекладом?¶

Так, спершу вирішіть долю кожної правки. Режим No Markup лише тимчасово приховує виправлення, і Microsoft попереджає, що вони з’являться знову після повторного відкриття документа.

Які довідкові матеріали надіслати перекладачеві?¶

Передайте чинний глосарій, стильовий посібник, затверджені попередні переклади й примітки про аудиторію, продукт та неоднозначні фрагменти. Позначте, які матеріали мають перевагу, а старі або суперечливі файли вилучіть чи чітко позначте як неактуальні.

Як підготувати програмні рядки та плейсхолдери до перекладу?¶

Передавайте повні повідомлення, а не склеєні частини, і пояснюйте значення кожної змінної. Додайте приклад її значення, місце показу рядка, умови використання та відомі обмеження довжини чи символів.

Чому перекладачеві потрібен фінальний вихідний файл і контекст?¶

Фінальний файл визначає текст, який треба перекласти, а контекст пояснює значення термінів і рядків. Зміни після початку роботи можуть вимагати повторного редагування, тому зафіксуйте версію й повідомляйте про всі оновлення.