Make some corrections

Author: illright

i18n/en/docusaurus-plugin-content-docs/current/get-started/overview.mdx

@@ -2,7 +2,7 @@
 sidebar_position: 1
 ---
 
-# Overview {#overview}
+# Overview
 
 **Feature-Sliced Design** (FSD) is an architectural methodology for scaffolding front-end applications. Simply put, it's a compilation of rules and conventions on organizing code. The main purpose of this methodology is to make the project more understandable and stable in the face of ever-changing business requirements.
 
@@ -87,11 +87,11 @@ Slices cannot use other slices on the same layer, and that helps with high cohes
 
 Slices, as well as layers App and Shared, consist of segments, and segments group your code by its purpose. Segment names are not constrained by the standard, but there are several conventional names for the most common purposes:
 
-- `ui` — self-explanatory
-- `api` — also self-explanatory
-- `model` — the data model: schemas, interfaces, stores, and business logic
-- `lib` — library code that's only used within this slice
-- `config` — configuration files and feature flags
+- `ui` — everything related to UI display: UI components, date formatters, styles, etc.
+- `api` — backend interactions: request functions, data types, mappers, etc.
+- `model` — the data model: schemas, interfaces, stores, and business logic.
+- `lib` — library code that other modules on this slice need.
+- `config` — configuration files and feature flags.
 
 Usually these segments are enough for most layers, you would only create your own segments in Shared or App, but this is not a rule.
 
@@ -115,7 +115,7 @@ Usually these segments are enough for most layers, you would only create your ow
 
 If you have an existing codebase that you want to migrate to FSD, we suggest the following strategy. We found it useful in our own migration experience.
 
-1. Start by slowly shaping up the App and Shared layers module-by-module to create a foundation. Usually, these layers are the smallest.
+1. Start by slowly shaping up the App and Shared layers module-by-module to create a foundation.
 
 2. Distribute all of the existing UI across Widgets and Pages using broad strokes, even if they have dependencies that violate the rules of FSD.
 

i18n/ru/docusaurus-plugin-content-docs/current/get-started/overview.mdx

@@ -2,13 +2,13 @@
 sidebar_position: 1
 ---
 
-# Обзор {#overview}
+# Обзор
 
 **Feature-Sliced Design** (FSD) — это архитектурная методология для проектирования фронтенд-приложений. Проще говоря, это набор правил и соглашений по организации кода. Главная цель этой методологии — сделать проект понятнее и стабильнее в условиях постоянно меняющихся бизнес-требований.
 
 Помимо набора правил, FSD — это также целый инструментарий. У нас есть [линтер][ext-steiger] для проверки архитектуры вашего проекта, [генераторы папок][ext-tools] через CLI или IDE, а также богатая библиотека [примеров][examples].
 
-## Подходит ли она мне? {#is-it-right-for-me}
+## Подходит ли FSD мне? {#is-it-right-for-me}
 
 FSD можно внедрять в проектах и командах любого размера. Она подходит для вашего проекта, если:
 
@@ -87,35 +87,35 @@ _\* — эти слои, App и Shared, в отличие от других сл
 
 Слайсы, а также слои App и Shared, состоят из сегментов, а сегменты группируют код по его назначению. Имена сегментов не зафиксированы стандартом, но существует несколько общепринятых имен для наиболее распространенных целей:
 
-- `ui` — говорит само за себя
-- `api` — тоже говорит само за себя
+- `ui` — всё, что связано с отображением: UI-компоненты, форматтеры дат, стили и т.д.
+- `api` — взаимодействие с бэкендом: функции запросов, типы данных, мапперы.
 - `model` — модель данных: схемы валидации, интерфейсы, хранилища и бизнес-логика.
-- `lib` — библиотечный код, который используется только внутри этого слайса.
+- `lib` — библиотечный код, который нужен другим модулям этого слайса.
 - `config` — файлы конфигурации и фиче-флаги.
 
 Обычно этих сегментов достаточно для большинства слоев, поэтому свои собственные сегменты обычно создают только в Shared или App, но это не жёсткое правило.
 
 ## Преимущества {#advantages}
 
-- **Однородность**
+- **Однородность**  
  Поскольку структура стандартизирована, проекты становятся более единообразными, что облегчает набор новых участников в команду.
 
 - **Устойчивость к изменениям и рефакторингу**  
- Модуль на одном слое не может использовать другие модули на том же слое или слоях выше.
+ Модуль на одном слое не может использовать другие модули на том же слое или слоях выше.  
  Это позволяет вам вносить изолированные правки без непредвиденных последствий для остальной части приложения.
 
-- **Контролируемое переиспользование логики**
- В зависимости от уровня вы можете сделать код либо очень переиспользуемым, либо очень локальным.
+- **Контролируемое переиспользование логики**  
+ В зависимости от уровня вы можете сделать код либо очень переиспользуемым, либо очень локальным.  
  Это сохраняет баланс между соблюдением принципа **DRY** и практичностью.
 
-- **Ориентация на потребности бизнеса и пользователей**
+- **Ориентация на потребности бизнеса и пользователей**  
  Приложение разделено на бизнес-домены, и при именовании поощряется использование терминологии бизнеса, чтобы вы могли делать полезную работу в продукте, не вникая полностью во все другие несвязанные части проекта.
 
 ## Постепенное внедрение {#incremental-adoption}
 
 Если у вас есть существующая кодовая база, которую вы хотите перенести на FSD, мы предлагаем следующую стратегию. На нашем собственном опыте миграции она хорошо себя зарекомендовала.
 
-1. Начните постепенно формировать слои App и Shared, чтобы создать фундамент. Обычно эти слои самые маленькие.
+1. Начните постепенно формировать слои App и Shared, чтобы создать фундамент.
 
 2. Раскидайте весь существующий интерфейсный код по виджетам и страницам, даже если у них пока что есть зависимости, нарушающие правила FSD.