fix mistakes

Co-authored-by: Volodymyr Klymenko <klymenkodp@gmail.com>

Author: xom9ikk

content/docs/faq-versioning.md

@@ -28,23 +28,23 @@ React дотримується принципів [семантичного ве
 
 ### Відповідальне ставлення до стабільності {#commitment-to-stability}
 
-Змінюючи React, ми намагаємося спростити вивчення нових можливостей. Крім цього, ми намагаємося зберегти роботу старих API, навіть якщо потрібно їх перенесення в окремий пакет. Наприклад, [ми відмовилися від домішок кілька років тому](/blog/2016/07/13/mixins-considered-harmful.html) але вони досі підтримуються [через create-react-class](/docs/react-without-es6.html#mixins) і багато проектів продовжують їх використовувати в стабільному, застарілому коді.
+Змінюючи React, ми намагаємося спростити вивчення нових можливостей. Крім цього, ми намагаємося зберегти роботу старих API, навіть якщо потрібно їх перенесення в окремий пакет. Наприклад, [ми відмовилися від міксинів кілька років тому](/blog/2016/07/13/mixins-considered-harmful.html) але вони досі підтримуються [через create-react-class](/docs/react-without-es6.html#mixins) і багато проєктів продовжують їх використовувати у стабільному, застарілому коді.
 
-Більше мільйона розробників React використовують, підтримуючи мільйони компонентів. Тільки в кодовій базі Facebook більше 50 000 React-компонентів. Все це зобов'язує нас робити оновлення до нових версій якомога простіше. Якщо ми не надамо можливості для оновлення, люди застрягнуть на старих версіях. Ми тестуємо наші шляхи оновлення прямо у Facebook — якщо наша команда з 10 осіб може оновити більше 50 тисяч компонентів, ми думаємо, що з цим впораються і інші React-розробники. У багатьох випадках для оновлення синтаксису компонентів ми пишемо [скрипти автоматизації](https://github.com/reactjs/react-codemod) які викладаємо у відкритий доступ для загального використання.
+Більше мільйона розробників використовують React, підтримуючи мільйони компонентів. Тільки в кодовій базі Facebook більше 50 000 React-компонентів. Все це зобов'язує нас робити оновлення до нових версій якомога простіше. Якщо ми не надамо можливості для оновлення, люди застрягнуть у старих версіях. Ми тестуємо наші шляхи оновлення прямо у Facebook — якщо наша команда з 10 людей може оновити більше 50 тисяч компонентів, ми думаємо, що з цим впораються й інші React-розробники. У багатьох випадках для оновлення синтаксису компонентів ми пишемо [скрипти автоматизації](https://github.com/reactjs/react-codemod) які викладаємо у відкритий доступ для загального використання.
 
 ### Поступове оновлення через попередження {#gradual-upgrades-via-warnings}
 
 Збірки в режимі розробки в React включають безліч корисних попереджень. Коли можливо, ми додаємо попередження для майбутніх зворотно несумісних змін. Таким чином, якщо ваш додаток не показує попереджень в консолі в останньому релізі, значить воно готове до наступної мажорної версії. Це дозволяє вам оновлювати додаток компонент за компонентом поодинці.
 
-Попередження про розробку не вплинуть на поведінку вашої програми під час виконання. Таким чином, ви можете бути впевнені, що ваш додаток буде вести себе однаково в режимі розробки і продакшн-режимі. Різниця лише в тому, що продакшн-збірка не буде показувати попередження в консолі і що вона більш ефективна. (Якщо ви раптом помітили попередження в продакшн-режимі, відкрийте ішью.)
+Попередження про розробку не вплинуть на поведінку вашої програми під час виконання. Таким чином, ви можете бути впевнені, що ваш додаток буде вести себе однаково в режимі розробки і продакшн-режимі. Різниця лише в тому, що продакшн-збірка не буде показувати попередження в консолі і що вона більш ефективна. (Якщо ви раптом помітили попередження в продакшн-режимі, відкрийте іш'ю в репозиторії React.)
 
 ### Що вважається зворотно несумісною зміною? {#what-counts-as-a-breaking-change}
 
 Як правило, ми *не* підвищуємо мажорну версію для наступних змін:
 
 * **Попередження для розробників.** Оскільки вони не впливають на поведінку в продакшн-режимі, ми можемо додавати або змінювати існуючі попередження між мажорними версіями. Це дозволяє нам заздалегідь попереджати про нові мажорні зміни.
 * **APIs з приставкою `unstable_`.** Вони додають експериментальні можливості, в API яких ми не впевнені до кінця. Випускаючи такі можливості з приставкою `unstable_` ми можемо їх оновлювати і переходити до стабільного API швидше.
-* **Альфа і канаркова версії React.** Альфа-версії React дозволяють спробувати нові можливості раніше. Ми можемо вносити в них зміни на основі зворотного зв'язку, отриманого в період альфа-тестування. Якщо ви використовуєте такі версії, майте на увазі, що API може змінитися в стабільній версії.
+* **Альфа і канаркові версії React.** Альфа-версії React дозволяють спробувати нові можливості раніше. Ми можемо вносити в них зміни на основі зворотного зв'язку, отриманого в період альфа-тестування. Якщо ви використовуєте такі версії, майте на увазі, що API може змінитися в стабільній версії.
 * **Недокументовані API і внутрішні структури даних.** Ми не гарантуємо працездатність коду в разі використання `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` or `__reactInternalInstance$uk43rzhitjg` або інших внутрішніх змінних.
 
 Наша політика розроблена, щоб бути практичною. Ми не хочемо створювати вам головний біль. Якби ми піднімали мажорну версію занадто часто, то доставили б безліч проблем всій спільноті. І це б не дозволило покращувати React так швидко, як нам хотілося.