Розширення тексту під час перекладу з англійської на німецьку

Англійська кнопка «Save» займає мало місця, а німецький відповідник «Änderungen speichern» уже може не вміститися у вузьку панель. Якщо макет розрахований лише на англійську, переклад виявить проблему тоді, коли команда вже тестує готовий реліз, а не тоді, коли ще легко змінити компонування.

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

Microsoft пропонує подовжувати англійські рядки на 40% під час псевдолокалізації - автоматичного тесту, який імітує наслідки перекладу, не підміняючи його справжнім. Ці 40% - корисна евристика для пошуку проблем компонування, а не обіцянка, що німецький текст завжди буде саме на стільки довшим (Microsoft про псевдолокалізацію).

Що таке розширення тексту і чому воно важливе¶

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

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

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

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

Для команди корисно розділяти три питання:

• Чи передає переклад потрібний зміст?
• Чи правильно виглядає текст у заданому контексті?
• Чи вміщується текст у компонуванні на потрібному екрані?

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

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

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

Як працює псевдолокалізація і що вона показує¶

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

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

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

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

Практичний процес можна побудувати так:

1. Зберіть усі текстові ресурси, що показуються користувачам, і відокремте їх від рядків, які не потрапляють в інтерфейс.
2. Створіть псевдолокалізовану версію ресурсів із довшими рядками, помітними роздільниками й додатковими символами.
3. Запустіть застосунок з цими ресурсами та перевірте основні сценарії на різних розмірах екрана.
4. Запишіть дефекти за компонентом і типом проблеми: обрізання, накладання, невдале перенесення, некоректний шрифт або зламана навігація.
5. Виправте компонування, а потім перевірте його зі справжнім німецьким перекладом і в контексті.

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

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

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

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

Як німецькі слова впливають на кнопки, форми й компонування¶

Німецькі складні слова можуть виглядати незвично довгими для тих, хто проєктував інтерфейс англійською. Duden пояснює, що складені слова в німецькій зазвичай пишуть разом; серед прикладів наведено Wasser і Glas, які утворюють Wasserglas (Duden про складні слова). Для кнопки це означає, що текст може не мати пробілу, на якому команда очікувала перенос.

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

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

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

У таблиці нижче зібрані типові ризики та рішення, які варто перевірити на справжніх екранах.

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

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

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

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

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

Перенесення німецьких слів: коли допомагає CSS, а коли заважає¶

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

MDN описує три значення CSS-властивості hyphens: none, manual і auto. Початкове значення - manual; значення auto дозволяє браузеру переносити слова у відповідних місцях (MDN про властивість hyphens). Можливість доступна в сучасних браузерах, але підтримка функції сама собою не гарантує однаковий результат на кожному пристрої.

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

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

Duden пояснює, що дефіс у складних словах може уточнювати структуру або поліпшувати читабельність; серед прикладів є Mehrzweck-Küchenmaschine та Umsatzsteuer-Tabelle (правопис Duden про дефіс). Правописний дефіс у слові та можливість браузера перенести рядок - різні речі. Не вставляйте дефіс у переклад тільки для того, щоб виправити ширину кнопки: спершу перевірте макет і правила відображення.

У веброзмітці існує й м’який дефіс, який непомітний, доки браузеру не потрібно перенести слово саме в цьому місці. MDN розрізняє видимий символ U+2010 і м’який дефіс U+00AD, який показується лише в разі перенесення слова за відповідною позицією (довідка MDN). Ручне додавання таких символів може бути доречним для конкретного контенту, але створює додаткову вимогу до перевірки в різних місцях інтерфейсу.

Порівняйте три варіанти на реальному німецькому рядку:

• hyphens: none не дозволяє переносити слово засобами цієї властивості.
• hyphens: manual дає змогу враховувати ручні підказки перенесення, якщо вони є.
• hyphens: auto просить браузер шукати відповідні місця для поділу слова.

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

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

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

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

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

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

Особливо ризиковане складання речення з частин, коли граматика залежить від підставленої назви. У німецькій рід і артикль змінюються залежно від іменника. У прикладах Microsoft зустрічі відповідає «Der Termin», завданню - «Die Aufgabe», а документу - «Das Dokument». Якщо програмний рядок підставляє різні назви після спільного артикля, результат може бути граматично неправильним.

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

Перевірку локалізації варто розділити на три частини: функціональну, візуальну й мовну. Функціональна перевіряє, чи працюють елементи; візуальна - чи відображаються всі ресурси і чи можна користуватися інтерфейсом; мовна - чи доречний переклад. Саме такий поділ описує Microsoft у настанові з локалізаційного тестування (Microsoft, How to perform localization testing).

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

План локалізаційного тестування може мати такий вигляд:

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

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

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

Записуйте проблему так, щоб її можна було відтворити: назва екрана, рядок ресурсу, ширина вікна, компонент, очікувана поведінка та фактичний результат. Формулювання «тут не вміщується» корисне лише тому, хто вже дивиться на той самий екран. Запис «повідомлення про помилку перекриває кнопку на вузькій ширині екрана» дає команді чітку задачу без припущень про причину.

Типові помилки під час німецької локалізації інтерфейсу¶

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

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

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

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

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

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

Сьома помилка - налаштувати hyphens: auto і вважати проблему вирішеною. Для автоматичного перенесення потрібна мовна позначка та словник, а поведінка різниться між браузерами. Перевірте реальні пристрої та не покладайтеся на поділ слова в компонентах, де він ускладнює читання (MDN про CSS-перенесення).

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

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

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

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

За поясненням Microsoft про псевдолокалізацію: “When the source language is English, a good heuristic is to lengthen the text by 40%.”

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

Microsoft описує крайні випадки так: “In practice, there can be extreme cases where a string may be 200% or even 400% longer when translated into a real language.”

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

У довідці MDN про перенесення сказано: “Hyphenation rules are language-specific.”

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

FAQ¶

На скільки відсотків німецький текст довший за англійський?¶

Єдиного відсотка для всіх рядків немає. Microsoft пропонує збільшення на 40% як евристику для псевдолокалізації, а не як виміряний середній приріст саме для німецької (Microsoft).

Як перевірити розширення німецького тексту до завершення перекладу?¶

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

Як не дати німецькому складному слову вийти за межі кнопки?¶

Не задавайте кнопці жорстку ширину без запасу. Дозвольте їй рости або переносити напис, перевірте мінімальну ширину контейнера й протестуйте довгі слова в реальному інтерфейсі.

Чи варто автоматично переносити німецькі слова через CSS?¶

Властивість hyphens: auto може допомогти, але потрібні lang="de" і доступний словник перенесення. Перевірте вигляд у цільових браузерах і не покладайтеся на автоматичний поділ без тестування (MDN).

Як спроєктувати кнопки й форми для перекладу з англійської на німецьку?¶

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

Чому не можна перевірити весь інтерфейс лише за файлом перекладу?¶

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