Паведамленні пра памылкі і сістэмныя апавяшчэнні трэба перакладаць не літаральна, а функцыянальна: карыстальнік павінен адразу зразумець, што адбылося, чаму гэта здарылася і які наступны крок. Найлепшы варыянт — кароткі, дакладны і прыстасаваны да кантэксту прадукту і ўзроўню ведаў аўдыторыі. Калі паведамленне гучыць граматычна правільна, але не дапамагае дзейнічаць, з пункту гледжання UX яно ўсё роўна слабое.
На практыцы гэта значыць, што перакладаць error messages, alert’ы, валідатары і апавяшчэнні трэба з улікам тону брэнда, тыпу праграмы і абмежаванняў інтэрфейсу. Менавіта таму ўсё больш каманд карыстаюцца не толькі інструментамі кшталту пераклад online, але і рашэннямі, якія дазваляюць задаць стыль, фармальнасць і кантэкст паведамлення — як SmartTranslate.ai.
Чаму пераклад сістэмных паведамленняў складаней, чым здаецца?
На першы погляд сістэмныя паведамленні простыя: у іх некалькі слоў, значыць перакласці іх павінна быць лёгка. На практыцы ўсё наадварот. Чым карацейшы тэкст, тым менш месца, каб растлумачыць сэнс. Кожнае слова павінна трапляць дакладна, бо карыстальнік прымае рашэнне на падставе аднаго радка тэксту.
Праблема яшчэ і ў тым, што паведамленні з’яўляюцца ў моманты напружання: калі форма не працуе, плацеж адхілены, сесія скончылася або сістэма выявіла памылку ў праграме. У такі момант карыстальнік не хоча «прыгожага перакладу». Ён хоча ведаць:
- што здарылася,
- ці гэта ягоная памылка, ці збой сістэмы,
- што трэба зрабіць цяпер,
- ці ў бяспецы ягоныя даныя.
Таму перакласці “Invalid input” як «Правер уведзенае значэнне» можа быць лінгвістычна карэктна, але ўсё яшчэ мала карысна. У многіх выпадках лепш напісаць: «Правер уведзенае значэнне» або «Увядзі правільны адрас электроннай пошты». Гэта тонкая розніца, але з пункту гледжання UX — вельмі істотная.
Што павінна ўтрымліваць добрае паведамленне пасля перакладу?
Незалежна ад мовы, эфектыўнае сістэмнае паведамленне адказвае на тры пытанні: што адбылося, што гэта значыць і што карыстальніку рабіць далей. Не заўсёды ўсе гэтыя элементы трэба змяшчаць у адным сказе, але сэнс павінен быць ясны.
Добра перакладзенае паведамленне звычайна мае такія рысы:
- зразумелае для аўдыторыі — без лішняга тэхнічнага жаргону,
- канкрэтнае — кажа, які элемент трэба выпраўляць,
- кароткае — бо часта павінна змясціцца ў невялікім блоку UI,
- паслядоўнае — з тонам усёй праграмы,
- карыснае — падказвае наступны крок.
Гэта асабліва важна ў шматмоўных асяроддзях, дзе адно і тое ж паведамленне трэба падладжваць пад розныя рынкі, моўныя рэгістры і чаканні карыстальнікаў. Сам просты анлайн перакладчык або машынны перакладач можа не хапіць, калі ён не разумее кантэкст інтэрфейсу і ролю паведамлення, асабліва пры перакладзе дакументаў. Калі вам трэба, напрыклад, выбраць разнавіднасць мовы, гэта таксама ўплывае на тое, як будзе ўспрымацца паведамленне карыстальнікам.
Найчасцейшыя памылкі пры перакладзе error messages і alert’аў
1. Занадта літаральны пераклад
Адна з самых распаўсюджаных праблем — перакладаць слова ў слова. Сістэмныя паведамленні рэдка добра працуюць у такім фармаце, бо тэхнічныя ідыёмы і скарачэнні з адной мовы не заўсёды гучаць натуральна на другой.
Прыклад:
- EN: “An error occurred while processing your request.”
- Слаба: «Адбылася памылка падчас апрацоўкі вашага запыту.»
- Лепш: «Не ўдалося выканаць гэтую аперацыю. Паспрабуй яшчэ раз.»
Другі варыянт больш натуральны і лепш адпавядае намеру карыстальніка.
2. Лішак тэхнічнай мовы
Паведамленні, якія ствараюць тэхнічныя каманды, часта ўтрымліваюць тэрміны, зразумелыя праграмістам, але не канчатковым карыстальнікам. Пераклад такога тэксту без адаптацыі проста пераносіць праблему ў іншую мову.
Замест:
- «Токен аўтэнтыфікацыі скончыўся.»
лепш ужыць:
- «Сесія скончылася. Увайдзіце зноў.»
Карыстальніку не трэба ведаць механізм працы сістэмы. Яму важна ведаць, што рабіць.
3. Адсутнасць інструкцыі да дзеяння
Паведамленне тыпу «Памылка валідацыі» не дапамагае. Гэта інфармацыя пра стан сістэмы, а не падказка для чалавека. Калі поле абавязковае, трэба сказаць гэта адкрыта. Калі пароль занадта кароткі, варта пазначыць мінімальную даўжыню.
Лепшыя варыянты:
- «Гэта поле абавязковае.»
- «Пароль павінен змяшчаць не менш за 12 сімвалаў.»
- «Увядзіце правільны нумар тэлефона.»
4. Непаслядоўны тон камунікацыі
У адной частцы праграмы карыстальнік бачыць нейтральныя паведамленні, у другой — вельмі афіцыйныя, а яшчэ дзе-нідзе — штучна вольныя. Такая непаслядоўнасць зніжае давер да прадукту. Пры перакладзе трэба сачыць не толькі за сэнсам, але і за тонам.
5. Ігнараванне абмежаванняў інтэрфейсу
Нават найлепшы пераклад можа быць няўдалым, калі пасля ўкаранення ён не змяшчаецца ў кнопцы, дыялогавым акне або мабільнай форме. Мовы адрозніваюцца даўжынёй выразаў, таму паведамленне трэба тэставаць у рэальным UI, а не толькі ў табліцы з тэкстам.
Як знайсці баланс паміж сцісласцю і зразумеласцю?
Гэта адно з самых важных пытанняў пры перакладзе сістэмных паведамленняў. Занадта кароткі тэкст бывае неясным, а занадта доўгі запавольвае карыстальніка і засмечвае інтэрфейс. Добрая практыка — перадаць мінімум інфармацыі, неабходнай для дзеяння, ні менш, ні больш.
Можна скарыстаць простую мадэль:
- Назавіце праблему.
- Калі трэба, пакажыце прычыну.
- Дадайце наступнае дзеянне.
Прыклады:
- «Не ўдалося захаваць змены. Паспрабуйце яшчэ раз.»
- «Гэты адрас электроннай пошты ўжо выкарыстоўваецца. Увайдзіце або скарыстайцеся іншым.»
- «Файл занадта вялікі. Максімальны памер — 10 MB.»
Варта таксама памятаць, што не кожнае паведамленне павінна быць поўным сказам. У валідатарах формаў часта лепш працуюць ультракароткія, дакладныя паведамленні, напрыклад «Увядзіце правільны паштовы індэкс». А вось для крытычных памылак лепш дадаць крыху больш слоў, каб зменшыць раздражненне карыстальніка.
Розніца ў тоне: спажывецкі прадукт, B2B і адміністратарскія інструменты
Адзін і той жа сэнс можна перадаць некалькімі спосабамі. Выбар залежыць ад тыпу прадукту і аўдыторыі.
Спажывецкі прадукт
У праграмах для шырокай аўдыторыі найлепш працуе простая, падтрымліваючая і прамая мова. Карыстальнік не хоча адчуваць сябе асуджаным або пакаранным за памылку.
Прыклады:
- «Ой, нешта пайшло не так. Паспрабуй яшчэ раз.»
- «Увядзі правільны адрас электроннай пошты.»
- «Не ўдалося дадаць картку. Правер даныя і паспрабуй яшчэ раз.»
У гэтым сегменце можна дазволіць сабе крыху больш чалавечны тон, але без інфантылізацыі.
B2B-прадукт
У сістэмах B2B важныя прафесіяналізм, дакладнасць і эканомія слоў. Паведамленні ўсё роўна павінны быць зразумелымі, але звычайна менш «эмацыйнымі», чым у спажывецкіх праграмах.
Прыклады:
- «Не атрымалася захаваць змены. Правер правы карыстальніка.»
- «Экспарт не завершаны. Паспрабуй яшчэ раз праз некалькі хвілін.»
- «Не хапае абавязковых даных у полі ‘УНП’.»
Адміністратарскія і тэхнічныя інструменты
У панэлях адміністратара, аперацыйных сістэмах і тэхнічных бэк-офісах паведамленні могуць быць больш спецыялізаванымі, але ўсё роўна павінны весці да дзеяння. Карыстальнік такой сістэмы часта мае больш кампетэнцый, аднак гэта не азначае дазвол на нечытаемасць.
Прыклады:
- «Злучэнне з серверам было разарвана. Правер канфігурацыю сеткі.»
- «Не ўдалося абнавіць токен. Увайдзіце зноў.»
- «Няма доступу да рэсурсу. Правер ролі і правы доступу.»
Вось тут асабліва карысная магчымасць дакладна задаць стыль, тон і фармальнасць перакладу. SmartTranslate дазваляе прафіляваць пераклад пад галіну і тып камунікацыі, што вельмі практычна пры працы з прадуктамі для розных аўдыторый.
Як перакладаць канкрэтныя тыпы паведамленняў?
Паведамленні пра памылкі
Яны павінны ясна паказваць праблему і — калі гэта магчыма — падказваць рашэнне. Лепш пазбягаць сухіх фраз кшталту “Operation failed”.
Добрыя практыкі:
- пакажы прычыну, калі яна вядомая,
- не вінаваці карыстальніка,
- прапануй наступны крок.
Alert’ы і папярэджанні
Тут ключавая яснасць і патрэбны ўзровень тэрміновасці. Не кожнае папярэджанне павінна гучаць як трывога. Паведамленне павінна адлюстроўваць рэальную рызыку.
Прыклады:
- «Твая сесія скончыцца праз 2 хвіліны.»
- «Выдаленне гэтага файла незваротнае.»
- «Гэта змяненне закране ўсіх карыстальнікаў у арганізацыі.»
Валідацыйныя паведамленні
Гэта адны з самых частых тэкстаў у інтэрфейсе. Яны павінны быць максімальна канкрэтныя і прывязаныя да пэўнага поля.
Замест:
- «Няправільны фармат.»
лепш:
- «Увядзіце дату ў фармаце DD.MM.RRRR.»
- «Пароль павінен змяшчаць хаця б адну лічбу.»
- «Нумар замовы павінен мець 8 сімвалаў.»
Сістэмныя апавяшчэнні
Яны не заўсёды паведамляюць пра памылку. Часам яны пацвярджаюць выкананне дзеяння або стан працэсу. Іх пераклад таксама патрабуе паслядоўнасці і прастаты.
Прыклады:
- «Змены захаваны.»
- «Справаздача гатовая да спампоўкі.»
- «Мы адправілі спасылку для скіду пароля.»
Практычны працэс перакладу паведамленняў у прадуктовай камандзе
Калі хочаце палепшыць якасць сістэмных паведамленняў, варта ўвесці ўпарадкаваны працэс замест таго, каб перакладаць тэксты ad hoc.
- Збярыце ўсе паведамленні ў адным месцы — лепш разам з кантэкстам выкарыстання, назвай экрана і інфармацыяй пра абмежаванні па сімвалах.
- Пазначце тып паведамлення — памылка, валідацыя, папярэджанне, поспех, інфармацыя.
- Вызначце аўдыторыю — канчатковы карыстальнік, бізнес-кліент, адміністратар, падтрымка.
- Задайце тон і фармальнасць — асобна для кожнага прадукту або модуля.
- Праверце паведамленні ў інтэрфейсе — асабліва ў мабільнай версіі.
- Аналізуйце звароты ў support — калі карыстальнікі ўсё яшчэ пытаюцца, што азначае пэўнае паведамленне, яго трэба дапрацаваць.
На практыцы вялікай дапамогай становіцца інструмент, які падтрымлівае і кароткія фрагменты тэксту, і цэлыя файлы з паведамленнямі, захоўваючы іх структуру. Гэта асабліва важна, калі працуеце з файламі JSON, CSV, дакументамі Office або экспартнымі дадзенымі з сістэмы. SmartTranslate.ai добра ўпісваецца ў такі працэс, бо дазваляе перакладаць тэкст уручную або праз дакументы, захоўваючы фарматаванне і адаптуючы пераклад да абранага профілю.
Чаму звычайнага перакладчыка online не заўсёды дастаткова?
Многія пачынаюць з простых інструментаў, такіх як анлайн перакладчык, тэхнічны перакладач або перакладчык з рускай на беларускую, але для падтрымка IT у прадукце часта патрэбна больш дакладная адаптацыя. Гэта зразумела: яны хуткія і зручныя. Праблема ўзнікае тады, калі трэба паклапаціцца пра паслядоўнасць тону, фармальнасць, галіну і кантэкст UI.
Паведамленне “Access denied” можна перакласці некалькімі спосабамі, і выбар залежыць ад сітуацыі:
- «Няма доступу.»
- «У вас няма правоў на гэты рэсурс.»
- «Доступ заблакаваны.»
Кожны з гэтых варыянтаў мае розны практычны сэнс. Агульныя інструменты не заўсёды адрозніваюць такія нюансы. Падобна і пры перакладах на іншыя рынкі: пераклад на беларускую лацінку ці пераклад для help center можа дапамагчы ў хуткім чарнавіку, але для прадукцыйнага ўкаранення патрэбна лепшая адаптацыя.
Гэта ж датычыцца шматмоўных каманд, якія працуюць з перакладам дакументаў, падтрымкай карыстальнікаў і базай ведаў: у такіх сцэнарыях карысны не толькі машынны перакладач, але і дакладна настроены працэс лакалізацыі. Калі патрэбны больш надзейны перакладчык з рускай на беларускую або падтрымка IT-тэкстаў, важна ўлічваць і кантэкст, і тэрміналогію, і абмежаванні інтэрфейсу.