diff --git a/README.ukrainian.md b/README.ukrainian.md
index 8cca6563d..e3bf9520a 100644
--- a/README.ukrainian.md
+++ b/README.ukrainian.md
@@ -380,21 +380,17 @@ Read in a different language: [**CN**](./README.chin
**В іншому випадку:** Уявіть таку ситуацію – ваша функція очікує числовий аргумент "Знижка", який викликаюча сторона забуває передати, потім ваш код перевіряє, чи Знижка!=0 (розмір дозволеної знижки більший ніж нуль), тоді він дозволить користувачу отримати знижку. О боже, яка неприємна помилка. Бачите її?
-🔗 [**Читати більше: швидке виявлення помилок**](./sections/errorhandling/failfast.md)
+🔗 [**Читати більше: швидке виявлення помилок**](./sections/errorhandling/failfast.ukrainian.md)
-## ![✔] 2.12 Always await promises before returning to avoid a partial stacktrace
+## ![✔] 2.12 Завжди очікуйте проміси перед поверненням, щоб уникнути часткового стеку викликів
-**TL;DR:** Always do `return await` when returning a promise to benefit full error stacktrace. If a
-function returns a promise, that function must be declared as `async` function and explicitly
-`await` the promise before returning it
+**Коротко:** Завжди використовуйте `return await` при поверненні промісу, щоб отримати повний стек помилок. Якщо функція повертає проміс, ця функція повинна бути оголошена як `async` функція і явно використовувати `await` для промісу перед його поверненням
-**Otherwise:** The function that returns a promise without awaiting won't appear in the stacktrace.
-Such missing frames would probably complicate the understanding of the flow that leads to the error,
-especially if the cause of the abnormal behavior is inside of the missing function
+**В іншому випадку:** Функція, яка повертає проміс без очікування, не з'явиться у стеку викликів. Такі відсутні кадри, ймовірно, ускладнять розуміння потоку, що призвів до помилки, особливо якщо причина аномальної поведінки знаходиться всередині відсутньої функції
-🔗 [**Read More: returning promises**](./sections/errorhandling/returningpromises.md)
+🔗 [**Читати більше: повернення промісу**](./sections/errorhandling/returningpromises.ukrainian.md)
@@ -402,13 +398,13 @@ especially if the cause of the abnormal behavior is inside of the missing functi
# `3. Code Style Practices`
-## ![✔] 3.1 Use ESLint
+## ![✔] 3.1 Використовуйте ESLint
-**TL;DR:** [ESLint](https://eslint.org) is the de-facto standard for checking possible code errors and fixing code style, not only to identify nitty-gritty spacing issues but also to detect serious code anti-patterns like developers throwing errors without classification. Though ESLint can automatically fix code styles, other tools like [prettier](https://www.npmjs.com/package/prettier) and [beautify](https://www.npmjs.com/package/js-beautify) are more powerful in formatting the fix and work in conjunction with ESLint
+**Коротко:** [ESLint](https://eslint.org) є фактичним стандартом для перевірки можливих помилок у коді та виправлення стилю коду. Він допомагає не лише виявити дрібні проблеми зі структурою коду, такі як зайві пробіли, але й серйозні антипатерни коду, наприклад, коли розробники кидають помилки без класифікації. Хоча ESLint може автоматично виправляти стиль коду, інші інструменти, такі як [prettier](https://www.npmjs.com/package/prettier) і [beautify](https://www.npmjs.com/package/js-beautify), більш потужні у форматуванні виправлень і працюють разом з ESLint.
-**Otherwise:** Developers will focus on tedious spacing and line-width concerns and time might be wasted overthinking the project's code style
+**В іншому випадку:** Розробники зосереджуватимуться на нудних питаннях щодо пробілів та ширини рядків, а час може бути витрачено на надмірне обдумування стилю коду проєкту.
-🔗 [**Read More: Using ESLint and Prettier**](./sections/codestylepractices/eslint_prettier.md)
+🔗 [**Детальніше: Використання ESLint та Prettier**](./sections/codestylepractices/eslint_prettier.ukrainian.md)
diff --git a/sections/codestylepractices/eslint_prettier.ukrainian.md b/sections/codestylepractices/eslint_prettier.ukrainian.md
new file mode 100644
index 000000000..dddd08ed5
--- /dev/null
+++ b/sections/codestylepractices/eslint_prettier.ukrainian.md
@@ -0,0 +1,25 @@
+# Використання ESLint та Prettier
+
+### Порівняння ESLint та Prettier
+
+Якщо ви відформатуєте цей код за допомогою ESLint, він лише видасть попередження про те, що рядок занадто широкий (залежить від налаштувань `max-len`). Prettier автоматично відформатує його для вас.
+
+```javascript
+foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne(), noWayYouGottaBeKiddingMe());
+```
+
+```javascript
+foo(
+ reallyLongArg(),
+ omgSoManyParameters(),
+ IShouldRefactorThis(),
+ isThereSeriouslyAnotherOne(),
+ noWayYouGottaBeKiddingMe()
+);
+```
+
+Джерело: [https://github.com/prettier/prettier-eslint/issues/101](https://github.com/prettier/prettier-eslint/issues/101)
+
+### Інтеграція ESLint та Prettier
+
+ESLint та Prettier перетинаються у функції форматування коду, але їх можна легко поєднати за допомогою інших пакетів, таких як [prettier-eslint](https://github.com/prettier/prettier-eslint), [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) та [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier). Для отримання додаткової інформації про їхні відмінності, ви можете переглянути посилання [тут](https://stackoverflow.com/questions/44690308/whats-the-difference-between-prettier-eslint-eslint-plugin-prettier-and-eslint).
diff --git a/sections/errorhandling/failfast.ukraine.md b/sections/errorhandling/failfast.ukrainian.md
similarity index 100%
rename from sections/errorhandling/failfast.ukraine.md
rename to sections/errorhandling/failfast.ukrainian.md
diff --git a/sections/errorhandling/returningpromises.ukrainian.md b/sections/errorhandling/returningpromises.ukrainian.md
new file mode 100644
index 000000000..f3302436d
--- /dev/null
+++ b/sections/errorhandling/returningpromises.ukrainian.md
@@ -0,0 +1,283 @@
+# Повернення промісів
+
+
+
+### Пояснення за один абзац
+
+Коли виникає помилка, незалежно від того, чи це синхронний чи асинхронний потік, важливо мати повний стек викликів для потоку помилки. Дивно, але якщо асинхронна функція повертає проміс (наприклад, викликає іншу асинхронну функцію) без очікування, то у разі виникнення помилки функція-викликач не з'явиться у стеку викликів. Це залишить людину, яка діагностує помилку, з неповною інформацією - тим більше, якщо причина помилки лежить у межах цієї функції-викликача. Існує функція v8 під назвою "zero-cost async stacktraces", яка дозволяє стеку викликів не обриватися на останньому `await`. Але через нетривіальні деталі реалізації, вона не працюватиме, якщо значення, що повертається функцією (синхронною чи асинхронною), є промісом. Отже, щоб уникнути прогалин у стеках викликів, коли повернуті проміси будуть відхилені, ми завжди повинні явно вирішувати проміси за допомогою `await` перед їх поверненням з функцій.
+
+
+
+### Приклад коду Анти-Шаблон: Виклик асинхронної функції без очікування
+
+Javascript
+
+
+```javascript
+async function throwAsync(msg) {
+ await null // потрібно очікувати хоча б щось, щоб бути дійсно асинхронним (див. примітку #2)
+ throw Error(msg)
+}
+
+async function returnWithoutAwait () {
+ return throwAsync('відсутній returnWithoutAwait у стеку викликів')
+}
+
+// 👎 НЕ матиме returnWithoutAwait у стеку викликів
+returnWithoutAwait().catch(console.log)
+```
+
+виведе
+
+```
+Error: відсутній returnWithoutAwait у стеку викликів
+ at throwAsync ([...])
+```
+
+Javascript
+
+
+```javascript
+async function throwAsync(msg) {
+ await null // потрібно очікувати хоча б щось, щоб бути дійсно асинхронним (див. примітку #2)
+ throw Error(msg)
+}
+
+async function returnWithAwait() {
+ return await throwAsync('з усіма присутніми кадрами')
+}
+
+// 👍 матиме returnWithAwait у стеку викликів
+returnWithAwait().catch(console.log)
+```
+
+виведе
+
+```
+Error: з усіма присутніми кадрами
+ at throwAsync ([...])
+ at async returnWithAwait ([...])
+```
+
+
+
+
+### Приклад коду Анти-Шаблон: Повернення промісу без позначення функції як асинхронної
+
+Javascript
+
+
+```javascript
+async function throwAsync () {
+ await null // потрібно очікувати хоча б щось, щоб бути дійсно асинхронним (див. примітку #2)
+ throw Error('відсутній syncFn у стеку викликів')
+}
+
+function syncFn () {
+ return throwAsync()
+}
+
+async function asyncFn () {
+ return await syncFn()
+}
+
+// 👎 syncFn буде відсутня у стеку викликів, оскільки вона повертає проміс, будучи синхронною
+asyncFn().catch(console.log)
+```
+
+виведе
+
+```
+Error: відсутній syncFn у стеку викликів
+ at throwAsync ([...])
+ at async asyncFn ([...])
+```
+
+
+Javascript
+
+
+```javascript
+async function throwAsync () {
+ await null // потрібно очікувати хоча б щось, щоб бути дійсно асинхронним (див. примітку #2)
+ throw Error('з усіма присутніми кадрами')
+}
+
+async function changedFromSyncToAsyncFn () {
+ return await throwAsync()
+}
+
+async function asyncFn () {
+ return await changedFromSyncToAsyncFn()
+}
+
+// 👍 тепер changedFromSyncToAsyncFn буде присутня у стеку викликів
+asyncFn().catch(console.log)
+```
+
+виведе
+
+```
+Error: з усіма присутніми кадрами
+ at throwAsync ([...])
+ at changedFromSyncToAsyncFn ([...])
+ at async asyncFn ([...])
+```
+
+
+
+
+### Приклад коду Анти-шаблон #3: безпосереднє використання асинхронного зворотного виклику там, де очікується синхронний
+
+Javascript
+
+
+```javascript
+async function getUser (id) {
+ await null
+ if (!id) throw Error('у стеку викликів відсутнє місце, де було викликано getUser')
+ return {id}
+}
+
+const userIds = [1, 2, 0, 3]
+
+// 👎 стек викликів включатиме функцію getUser, але не дасть жодної підказки, де її було викликано
+Promise.all(userIds.map(getUser)).catch(console.log)
+```
+
+виведе
+
+```
+Error: у стеку викликів відсутнє місце, де було викликано getUser
+ at getUser ([...])
+ at async Promise.all (index 2)
+```
+
+*Примітка*: може здатися, що `Promise.all (index 2)` може допомогти зрозуміти, де було викликано `getUser`,
+але через [зовсім іншу помилку в v8](https://bugs.chromium.org/p/v8/issues/detail?id=9023), `(index 2)` є
+рядком з внутрішніх механізмів v8
+
+
+Javascript
+
+
+*Примітка 1*: якщо ви контролюєте код функції, яка викликатиме зворотний виклик - просто змініть цю функцію на
+асинхронну і додайте `await` перед викликом зворотного виклику. Нижче я припускаю, що ви не відповідаєте за код, який викликає
+зворотний виклик (або його зміна неприйнятна, наприклад, через зворотню сумісність)
+
+*Примітка 2*: досить часто використання асинхронного зворотного виклику в місцях, де очікується синхронний, взагалі не працюватиме. Це не про
+те, як виправити код, який не працює - це про те, як виправити стек викликів у випадку, якщо код вже працює як
+очікувалося
+
+```javascript
+async function getUser (id) {
+ await null
+ if (!id) throw Error('з усіма присутніми кадрами')
+ return {id}
+}
+
+const userIds = [1, 2, 0, 3]
+
+// 👍 тепер рядок нижче є у стеку викликів
+Promise.all(userIds.map(async id => await getUser(id))).catch(console.log)
+```
+
+виведе
+
+```
+Error: з усіма присутніми кадрами
+ at getUser ([...])
+ at async ([...])
+ at async Promise.all (index 2)
+```
+
+де завдяки явному `await` в `map`, кінець рядка `at async ([...])` вказуватиме на точне місце, де
+було викликано `getUser`
+
+*Примітка*: якщо асинхронна функція, яка обгортає `getUser`, пропустить `await` перед поверненням (анти-шаблон #1 + анти-шаблон #3)
+тоді у стеку викликів залишиться лише один кадр:
+
+```javascript
+[...]
+
+// 👎 анти-шаблон 1 + анти-шаблон 3 - у стеку викликів залишився лише один кадр
+Promise.all(userIds.map(async id => getUser(id))).catch(console.log)
+```
+
+виведе
+
+```
+Error: [...]
+ at getUser ([...])
+```
+
+
+
+
+## Розширене пояснення
+
+Механізми стеків викликів синхронних функцій та асинхронних функцій у реалізації v8 досить різні:
+синхронний стек викликів базується на **стеку**, наданому операційною системою, на якій працює Node.js (як у більшості мов програмування).
+Коли виконується асинхронна функція, **стек** операційної системи виштовхує її, як тільки
+функція доходить до свого першого `await`. Тому асинхронний стек викликів є сумішшю **стеку** операційної системи та відхиленого
+**ланцюжка вирішення промісів**. Реалізація асинхронних стеків викликів з нульовою вартістю розширює **ланцюжок вирішення промісів**
+тільки тоді, коли проміс очікується за допомогою `await` [¹](#1). Оскільки тільки `async` функції можуть використовувати `await`,
+синхронна функція завжди буде відсутня в асинхронному стеку викликів, якщо будь-яка асинхронна операція була виконана після того,
+як функція була викликана [²](#2)
+
+### Компроміс
+
+Кожен `await` створює нову мікрозадачу в циклі подій, тому додавання більшої кількості `await` до коду
+призведе до деякого зниження продуктивності. Тим не менш, зниження продуктивності, спричинене мережею або
+базою даних, є [надзвичайно більшим](https://colin-scott.github.io/personal_website/research/interactive_latency.html),
+тому додаткова затримка від `await` не є чимось, що слід враховувати під час розробки веб-серверів або CLI,
+якщо тільки це не дуже гарячий код для запиту або команди. Тому видалення `await` у
+`return await` повинно бути одним з останніх місць для пошуку помітного підвищення продуктивності і
+точно ніколи не повинно робитися заздалегідь.
+
+
+### Чому return await вважався анти-шаблоном у минулому
+
+Існує ряд [чудових статей](https://jakearchibald.com/2017/await-vs-return-vs-return-await/), які пояснюють,
+чому `return await` ніколи не слід використовувати поза блоком `try`, і навіть
+[правило ESLint](https://eslint.org/docs/rules/no-return-await), яке забороняє його. Причина цього полягає в тому, що
+з моменту, коли async/await стали доступними з транспіляторами в Node.js 0.10 (і отримали нативну підтримку в Node.js 7.6) і до
+того, як "асинхронні стеки викликів з нульовою вартістю" були введені в Node.js 10 і розблоковані в Node.js 12, `return await` був абсолютно
+еквівалентним `return` для будь-якого коду поза блоком `try`. Це може все ще бути так для деяких інших ES-двигунів. Ось чому
+вирішення промісів перед їх поверненням є найкращою практикою для Node.js, а не для EcmaScript в цілому.
+
+### Примітки:
+
+1. Ще одна причина, чому асинхронний стек викликів має таку хитру реалізацію, - це обмеження, що стек викликів
+ завжди повинен будуватися синхронно, на тому ж тику циклу подій [¹](#1)
+2. Без `await` в `throwAsync` код буде виконуватися в тій же фазі циклу подій. Це
+ вироджений випадок, коли **стек** ОС не буде порожнім і стек викликів буде повним навіть без явного
+ очікування результату функції. Зазвичай використання промісів включає деякі асинхронні операції, і тому частини
+ стеку викликів будуть втрачені
+3. Асинхронні стеки викликів з нульовою вартістю все ще не працюватимуть для складних використань промісів, наприклад, коли один проміс
+ очікується багато разів у різних місцях
+
+### Посилання:
+1. [Блог-пост про асинхронні стеки викликів з нульовою вартістю в v8](https://v8.dev/blog/fast-async)
+
+
+2. [Документ про асинхронні стеки викликів з нульовою вартістю із згаданими тут деталями реалізації](
+https://docs.google.com/document/d/13Sy_kBIJGP0XT34V1CV3nkWya4T