click0 · January 24, 2026 14:51
diff --git a/bugs-ua.html b/bugs-ua.html
 <!DOCTYPE html>
 <html lang="uk">
 <head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <title>Як ефективно повідомляти про помилки</title>
 <style>
 body {
    font-family: Georgia, "Times New Roman", serif;
    max-width: 800px;
    margin: 40px auto;
    padding: 0 20px;
    line-height: 1.6;
    color: #333;
 }
 h2, h3 {
    color: #000;
    margin-top: 1.5em;
 }
 h2 {
    border-bottom: 1px solid #ccc;
    padding-bottom: 0.3em;
 }
 em {
    font-style: italic;
 }
 ul {
    margin: 1em 0;
 }
 li {
    margin-bottom: 0.5em;
 }
 hr {
    border: none;
    border-top: 1px solid #ccc;
    margin: 2em 0;
 }
 a {
    color: #0066cc;
 }
 .languages {
    text-align: center;
    margin: 1em 0;
    font-size: 0.9em;
 }
 .author {
    font-style: italic;
    margin-bottom: 2em;
 }
 .disclaimer {
    font-style: italic;
    margin-top: 2em;
    font-size: 0.9em;
 }
 .copyright {
    margin-top: 2em;
    font-size: 0.9em;
 }
 </style>
 </head>
 <body>

 <h2>Як ефективно повідомляти про помилки</h2>

 <p class="author">Саймон Тетем, професійний розробник вільного програмного забезпечення</p>

 <p class="languages">
 [
 <a href="bugs.html">English</a> |
 <a href="bugs-br.html">Português</a> |
 <a href="bugs-cn.html">简体中文</a> |
 <a href="bugs-cz.html">Česky</a> |
 <a href="bugs-da.html">Dansk</a> |
 <a href="bugs-de.html">Deutsch</a> |
 <a href="bugs-es.html">Español</a> |
 <a href="bugs-fr.html">Français</a> |
 <a href="bugs-hu.html">Magyar</a> |
 <a href="bugs-it.html">Italiano</a> |
 <a href="bugs-jp.html">日本語</a> |
 <a href="bugs-nl.html">Nederlands</a> |
 <a href="bugs-pl.html">Polski</a> |
 <a href="bugs-ru.html">Русский</a> |
 <a href="bugs-tw.html">繁體中文</a> |
 <strong>Українська</strong>
 ]
 </p>

 <h3>Вступ</h3>

 <p>Кожен, хто коли-небудь писав програмне забезпечення для широкого використання, напевно отримував хоча б один поганий звіт про помилку. Звіти, що нічого не кажуть («Воно не працює!»); звіти, що не мають сенсу; звіти без достатньої кількості інформації; звіти з <em>неправильною</em> інформацією. Звіти про проблеми, які виявляються помилками користувача; звіти про проблеми, що виявляються виною чужої програми; звіти про проблеми, що виявляються збоями мережі.</p>

 <p>Є причина, чому технічна підтримка вважається жахливою роботою, і ця причина — погані звіти про помилки. Однак не всі звіти про помилки неприємні: коли я не заробляю на життя, я підтримую вільне програмне забезпечення, і іноді отримую чудово зрозумілі, корисні та <em>інформативні</em> звіти про помилки.</p>

 <p>У цьому есе я спробую чітко сформулювати, що робить звіт про помилку хорошим. В ідеалі я хотів би, щоб усі у світі прочитали це есе, перш ніж повідомляти про будь-які помилки будь-кому. Безумовно, я хотів би, щоб усі, хто повідомляє про помилки <em>мені</em>, прочитали його.</p>

 <p>Коротко кажучи, мета звіту про помилку — дати програмісту можливість побачити, як програма збоїть, на власні очі. Ви можете або показати їм особисто, або дати ретельні та детальні інструкції, як відтворити збій. Якщо вони зможуть його відтворити, вони спробують зібрати додаткову інформацію, поки не знайдуть причину. Якщо вони не зможуть його відтворити, їм доведеться попросити вас зібрати цю інформацію замість них.</p>

 <p>У звітах про помилки намагайтеся чітко розмежовувати факти («Я був за комп'ютером і сталося ось це») та припущення («Я <em>думаю</em>, що проблема може бути в цьому»). Припущення можна опустити, якщо хочете, але факти опускати не можна.</p>

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

 <h3>«Воно не працює.»</h3>

 <p>Визнайте за програмістом базовий інтелект: якби програма справді взагалі не працювала, вони б, мабуть, це помітили. Оскільки вони не помітили, значить, у них вона працює. Отже, або ви робите щось інакше, ніж вони, або ваше середовище відрізняється від їхнього. Їм потрібна інформація; надання цієї інформації і є метою звіту про помилку. Більше інформації майже завжди краще, ніж менше.</p>

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

 <p>Це есе повне рекомендацій. Жодна з них не є абсолютним правилом. Конкретні програмісти мають свої особливі уподобання щодо того, як слід повідомляти про помилки. Якщо програма поставляється з власним набором інструкцій щодо звітування про помилки, прочитайте їх. Якщо інструкції, що постачаються з програмою, суперечать рекомендаціям у цьому есе, дотримуйтесь тих, що постачаються з програмою!</p>

 <p>Якщо ви не повідомляєте про помилку, а просто просите допомоги у використанні програми, вам слід вказати, де ви вже шукали відповідь на своє запитання. («Я переглянув розділ 4 і підрозділ 5.2, але не знайшов нічого, що б сказало мені, чи це можливо.») Це дасть програмісту знати, де люди очікують знайти відповідь, щоб вони могли зробити документацію зручнішою.</p>

 <h3>«Покажіть мені.»</h3>

 <p>Один з найкращих способів повідомити про помилку — показати її програмісту. Поставте їх перед своїм комп'ютером, запустіть їхнє програмне забезпечення та продемонструйте те, що йде не так. Нехай вони дивляться, як ви запускаєте машину, дивляться, як ви запускаєте програму, дивляться, як ви взаємодієте з програмою, і дивляться, що програма робить у відповідь на ваші дії.</p>

 <p>Вони знають це програмне забезпечення як свої п'ять пальців. Вони знають, яким частинам довіряють, і знають, у яких частинах ймовірно є недоліки. Вони інтуїтивно знають, на що звертати увагу. До того моменту, коли програма зробить щось очевидно неправильне, вони вже могли помітити щось <em>непомітно</em> неправильне раніше, що може дати їм підказку. Вони можуть спостерігати за всім, що комп'ютер робить під час тестового запуску, і самостійно виділяти важливі деталі.</p>

 <p>Цього може бути недостатньо. Вони можуть вирішити, що їм потрібно більше інформації, і попросити вас показати те саме знову. Вони можуть попросити вас описати процедуру покроково, щоб вони могли відтворити помилку самостійно стільки разів, скільки захочуть. Вони можуть спробувати трохи змінити процедуру, щоб побачити, чи проблема виникає лише в одному випадку, чи в цілій групі схожих випадків. Якщо вам не пощастить, їм може знадобитися сісти на пару годин з набором інструментів розробки та <em>справді</em> почати досліджувати. Але найважливіше — щоб програміст дивився на комп'ютер, коли щось йде не так. Як тільки вони зможуть побачити проблему, що відбувається, вони зазвичай можуть діяти далі і почати намагатися її виправити.</p>

 <h3>«Покажіть мені, як показати собі.»</h3>

 <p>Це ера Інтернету. Це ера всесвітньої комунікації. Це ера, коли я можу відправити своє програмне забезпечення комусь, наприклад, у Німеччині одним натисканням кнопки, і він може так само легко надіслати мені свої коментарі. Але якщо у нього проблема з моєю програмою, він <em>не може</em> поставити мене перед нею, поки вона збоїть. «Покажіть мені» — це добре, коли можливо, але часто це неможливо.</p>

 <p>Якщо вам потрібно повідомити про помилку програмісту, який не може бути присутнім особисто, мета вправи — дати йому можливість <em>відтворити</em> проблему. Ви хочете, щоб програміст запустив свою власну копію програми, зробив з нею те саме і змусив її збоїти так само. Коли вони зможуть побачити проблему на власні очі, тоді вони зможуть з нею впоратися.</p>

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

 <p>Надайте програмісту всю вхідну інформацію, яку можете придумати. Якщо програма читає з файлу, вам, ймовірно, потрібно буде надіслати копію файлу. Якщо програма спілкується з іншим комп'ютером через мережу, ви, ймовірно, не зможете надіслати копію того комп'ютера, але ви можете принаймні сказати, який це тип комп'ютера і (якщо можете) яке програмне забезпечення на ньому працює.</p>

 <h3>«У мене працює. То що йде не так?»</h3>

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

 <p>Тому також опишіть, що сталося. Скажіть їм точно, що ви побачили. Скажіть їм, чому ви думаєте, що те, що ви побачили, є неправильним; ще краще — скажіть їм точно, що ви очікували побачити. Якщо ви скажете «а потім щось пішло не так», ви пропустили дуже важливу інформацію.</p>

 <p>Якщо ви бачили повідомлення про помилки, скажіть програмісту ретельно та точно, якими вони були. Вони <em>важливі!</em> На цьому етапі програміст не намагається виправити проблему: він просто намагається її знайти. Їм потрібно знати, що пішло не так, і ці повідомлення про помилки — це найкраща спроба комп'ютера сказати вам це. Запишіть помилки, якщо у вас немає іншого простого способу їх запам'ятати, але не варто повідомляти, що програма видала помилку, якщо ви також не можете повідомити, яким було повідомлення про помилку.</p>

 <p>Зокрема, якщо повідомлення про помилку містить числа, <em>обов'язково</em> передайте ці числа програмісту. Те, що ви не бачите в них сенсу, не означає, що його там немає. Числа містять усілякі відомості, які можуть прочитати програмісти, і вони, ймовірно, містять життєво важливі підказки. Числа в повідомленнях про помилки є там тому, що комп'ютер занадто збентежений, щоб повідомити про помилку словами, але робить усе можливе, щоб якось донести до вас важливу інформацію.</p>

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

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

 <h3>«Тоді я спробував...»</h3>

 <p>Є багато речей, які ви можете зробити, коли виникає помилка або збій. Багато з них погіршують проблему. Моя подруга в школі випадково видалила всі свої документи Word, і перш ніж звернутися за допомогою до експерта, вона спробувала перевстановити Word, а потім запустити дефрагментацію диска. Жодне з цього не допомогло відновити її файли, і разом вони так перемішали диск, що жодна програма Undelete у світі не змогла б нічого відновити. Якби вона просто залишила все як є, у неї міг би бути шанс.</p>

 <p>Такі користувачі схожі на мангуста, загнаного в кут: приперти до стіни і бачачи неминучу смерть, він несамовито атакує, бо робити щось має бути краще, ніж не робити нічого. Це погано адаптовано до типу проблем, які створюють комп'ютери.</p>

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

 <p>Коли щось йде не так, негайно припиніть робити <em>будь-що</em>. Не натискайте жодних кнопок. Подивіться на екран і помітьте все незвичайне, і запам'ятайте або запишіть. Потім, можливо, обережно почніть натискати «OK» або «Скасувати», що здається безпечнішим. Спробуйте виробити рефлекторну реакцію — якщо комп'ютер робить щось несподіване, завмріть.</p>

 <p>Якщо вам вдається вибратися з проблеми, закривши уражену програму або перезавантаживши комп'ютер, хорошим кроком буде спробувати змусити її повторитися. Програмісти люблять проблеми, які вони можуть відтворити більше одного разу. Щасливі програмісти виправляють помилки швидше та ефективніше.</p>

 <h3>«Я думаю, що тахіонна модуляція має бути неправильно поляризована.»</h3>

 <p>Не тільки непрограмісти створюють погані звіти про помилки. Деякі з найгірших звітів про помилки, які я коли-небудь бачив, надходять від програмістів, і навіть від хороших програмістів.</p>

 <p>Колись я працював з іншим програмістом, який постійно знаходив помилки у своєму власному коді і намагався їх виправити. Час від часу він натрапляв на помилку, яку не міг вирішити, і кликав мене на допомогу. «Що пішло не так?» — питав я. Він відповідав, розповідаючи мені свою поточну думку про те, що потрібно виправити.</p>

 <p>Це прекрасно працювало, коли його поточна думка була правильною. Це означало, що він уже зробив половину роботи, і ми могли закінчити справу разом. Це було ефективно і корисно.</p>

 <p>Але досить часто він помилявся. Ми працювали деякий час, намагаючись зрозуміти, чому якась конкретна частина програми видає неправильні дані, і врешті-решт виявляли, що вона не видає, що ми досліджували абсолютно справний код півгодини, і що фактична проблема десь в іншому місці.</p>

 <p>Я впевнений, що він не зробив би цього з лікарем. «Лікарю, мені потрібен рецепт на гідрояйодин.» Люди знають, що так не кажуть лікарю: ви описуєте симптоми, фактичний дискомфорт, біль, висип і гарячку, і дозволяєте лікарю поставити діагноз, в чому проблема і що з цим робити. Інакше лікар відхилить вас як іпохондрика або божевільного, і цілком справедливо.</p>

 <p>Так само і з програмістами. Надання власного діагнозу іноді може бути корисним, але завжди повідомляйте симптоми. Діагноз — це необов'язковий додаток, а не альтернатива наданню симптомів. Так само надсилання модифікації коду для виправлення проблеми є корисним доповненням до звіту про помилку, але не адекватною заміною.</p>

 <p>Якщо програміст просить у вас додаткову інформацію, не вигадуйте її! Одного разу хтось повідомив мені про помилку, і я попросив його спробувати команду, яка, як я знав, не спрацює. Причина, чому я попросив його спробувати її, полягала в тому, що я хотів знати, яке з двох різних повідомлень про помилку вона видасть. Знання того, яке повідомлення про помилку повернеться, дало б важливу підказку. Але він насправді не спробував — він просто написав мені у відповідь: «Ні, це не спрацює». Мені знадобився деякий час, щоб переконати його спробувати насправді.</p>

 <p>Використовувати свій інтелект, щоб допомогти програмісту — це нормально. Навіть якщо ваші висновки неправильні, програміст має бути вдячний, що ви принаймні <em>намагалися</em> полегшити їм життя. Але повідомляйте також симптоми, інакше ви можете зробити їхнє життя набагато складнішим.</p>

 <h3>«Дивно, воно щойно це зробило.»</h3>

 <p>Скажіть «періодична несправність» будь-якому програмісту і спостерігайте, як його обличчя витягується. Легкі проблеми — це ті, де виконання простої послідовності дій викличе збій. Програміст може потім повторити ці дії в умовах ретельного спостереження і дуже детально подивитися, що відбувається. Занадто багато проблем просто не працюють таким чином: є програми, які збоять раз на тиждень, або збоять раз у сто років, або ніколи не збоять, коли ви намагаєтесь продемонструвати їх програмісту, але завжди збоять, коли наближається дедлайн.</p>

 <p>Більшість періодичних несправностей насправді не є справді періодичними. У більшості з них десь є якась логіка. Деякі можуть виникати, коли машині бракує пам'яті, деякі можуть виникати, коли інша програма намагається змінити критичний файл в невдалий момент, а деякі можуть виникати лише в першій половині кожної години! (Я справді бачив таке.)</p>

 <p>Крім того, якщо ви можете відтворити помилку, а програміст не може, цілком може бути, що їхній комп'ютер і ваш комп'ютер чимось відрізняються, і ця різниця спричиняє проблему. Колись у мене була програма, вікно якої згорталося в маленьку кульку в верхньому лівому куті екрана і сиділо там, <em>надувшись</em>. Але це траплялося лише на екранах 800x600; на моєму моніторі 1024x768 все було добре.</p>

 <p>Програміст захоче знати все, що ви можете дізнатися про проблему. Спробуйте на іншій машині, можливо. Спробуйте два-три рази і подивіться, як часто вона збоїть. Якщо вона йде не так, коли ви робите серйозну роботу, але не коли ви намагаєтеся її продемонструвати, можливо, тривалий час роботи або великі файли змушують її падати. Постарайтеся згадати якомога більше деталей про те, що ви з нею робили, коли вона впала, і якщо ви помітите якісь закономірності, згадайте їх. Все, що ви можете надати, має бути корисним. Навіть якщо це лише ймовірнісне (наприклад, «вона має тенденцію частіше падати, коли працює Emacs»), це може не дати прямих підказок до причини проблеми, але може допомогти програмісту її відтворити.</p>

 <p>Найголовніше, програміст захоче бути впевненим, чи він має справу зі справжньою періодичною несправністю, чи з несправністю, специфічною для машини. Вони захочуть знати багато деталей про ваш комп'ютер, щоб вони могли зрозуміти, чим він відрізняється від їхнього. Багато з цих деталей залежатимуть від конкретної програми, але одне, що ви точно повинні бути готові надати — це номери версій. Номер версії самої програми, і номер версії операційної системи, і, ймовірно, номери версій будь-яких інших програм, залучених до проблеми.</p>

 <h3>«Тоді я завантажив диск на свій Windows...»</h3>

 <p>Чітке письмо є essential у звіті про помилку. Якщо програміст не може зрозуміти, що ви мали на увазі, ви могли б взагалі нічого не говорити.</p>

 <p>Я отримую звіти про помилки з усього світу. Багато з них від людей, для яких англійська не є рідною мовою, і багато з них вибачаються за свою погану англійську. Загалом, звіти про помилки з вибаченнями за погану англійську насправді дуже зрозумілі та корисні. Усі найнезрозуміліші звіти надходять від носіїв англійської мови, які припускають, що я їх зрозумію, навіть якщо вони не докладають жодних зусиль, щоб бути зрозумілими чи точними.</p>

 <ul>
 <li><em>Будьте конкретними.</em> Якщо ви можете зробити те саме двома різними способами, вкажіть, який ви використали. «Я вибрав Завантажити» може означати «Я клацнув на Завантажити» або «Я натиснув Alt-L». Скажіть, що ви зробили. Іноді це має значення.</li>

 <li><em>Будьте багатослівними.</em> Надавайте більше інформації, а не менше. Якщо ви скажете занадто багато, програміст може проігнорувати частину. Якщо ви скажете занадто мало, їм доведеться повертатися і ставити більше запитань. Один звіт про помилку, який я отримав, був одним реченням; кожного разу, коли я просив більше інформації, автор відповідав іншим одним реченням. Мені знадобилося кілька тижнів, щоб отримати корисну кількість інформації, тому що вона надходила по одному короткому реченню за раз.</li>

 <li><em>Будьте обережні із займенниками.</em> Не використовуйте слова на кшталт «воно» або посилання на кшталт «це вікно», коли незрозуміло, що вони означають. Розгляньте це: «Я запустив FooApp. Вона вивела вікно попередження. Я спробував його закрити, і вона впала.» Незрозуміло, що користувач намагався закрити. Чи намагалися вони закрити вікно попередження, чи весь FooApp? Це має значення. Натомість ви могли б сказати: «Я запустив FooApp, яка вивела вікно попередження. Я спробував закрити вікно попередження, і FooApp впала.» Це довше і більш повторюване, але також зрозуміліше і менш легко неправильно зрозуміти.</li>

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

 <h3>Підсумок</h3>

 <ul>
 <li>Перша мета звіту про помилку — дати програмісту можливість побачити збій на власні очі. Якщо ви не можете бути поруч, щоб показати збій перед ними, надайте їм детальні інструкції, щоб вони могли відтворити його самостійно.</li>

 <li>У випадку, якщо перша мета не вдається, і програміст <em>не може</em> побачити збій самостійно, друга мета звіту про помилку — описати, що пішло не так. Опишіть все детально. Вкажіть, що ви бачили, а також вкажіть, що ви очікували побачити. Запишіть повідомлення про помилки, <em>особливо</em> якщо вони містять числа.</li>

 <li>Коли ваш комп'ютер робить щось несподіване, <em>завмріть</em>. Не робіть нічого, поки не заспокоїтесь, і не робіть нічого, що, на вашу думку, може бути небезпечним.</li>

 <li>Обов'язково спробуйте діагностувати несправність самостійно, якщо вважаєте, що можете, але якщо ви це робите, ви все одно повинні повідомити симптоми.</li>

 <li>Будьте готові надати додаткову інформацію, якщо програмісту вона потрібна. Якщо б вона їм не була потрібна, вони б не просили. Вони не намагаються навмисно ускладнити вам життя. Тримайте номери версій під рукою, тому що вони, ймовірно, знадобляться.</li>

 <li>Пишіть чітко. Кажіть те, що маєте на увазі, і переконайтеся, що це не можна неправильно зрозуміти.</li>

 <li>Понад усе, <em>будьте точними</em>. Програмісти люблять точність.</li>
 </ul>

 <hr>

 <p class="disclaimer"><em>Застереження:</em> Я насправді ніколи не бачив мангуста чи антилопу. Моя зоологія може бути неточною.</p>

 <div class="copyright">
 <p>Copyright © 1999 Simon Tatham.</p>
 <p>Цей документ — <a href="https://www.opencontent.org/">OpenContent</a>.</p>
 <p>Ви можете копіювати і використовувати його на умовах <a href="https://www.opencontent.org/openpub/">ліцензії OpenContent Licence</a>.</p>
 <p>Критику та зауваження щодо цієї статті (англійською мовою) надсилайте на адресу <a href="mailto:[email protected]">[email protected]</a>.</p>
 <p>Зауваження щодо перекладу надсилайте на адресу <a href="mailto:[email protected]">[email protected]</a>.</p>
 <p>Якщо ви потрапили на цю сторінку за посиланням з сайту конкретної програми, не надсилайте повідомлення про помилки цієї програми на адреси, наведені вище. Натомість поверніться на сторінку, з якої ви сюди прийшли, щоб дізнатися, куди надсилати повідомлення про помилки в цій програмі.</p>
 </div>

 </body>
 </html>
No results found