FIX: typography of public-api article

i18n/ru/docusaurus-plugin-content-docs/current/reference/public-api.md

@@ -31,11 +31,11 @@ export * from "./ui/Comment";  // 👎 не пытайтесь повторит
 export * from "./model/comments";  // 💩 это плохая практика
 ```
 
-Это ухудшает понимаемость слайса беглым взглядом, потому что вы не можете легко определить, каков интерфейс этого слайса. Не зная интерфейс, вам придется глубоко погружаться в код слайса, чтобы понять, как его интегрировать. Еще одна проблема заключается в том, что вы можете случайно раскрыть внутренние модули, что усложнит рефакторинг, если кто-то начнет от них зависеть.
+Это приводит к трудностям определения роли конкретного слайса (его интерфейса). Не зная интерфейс, вам придется глубоко погружаться в код слайса, чтобы понять, как его интегрировать. Еще одна проблема заключается в том, что вы можете случайно раскрыть внутренние модули, что усложнит рефакторинг, если кто-то начнет от них зависеть.
 
 ## Публичный API для кросс-импортов {#public-api-for-cross-imports}
 
-Кросс-импорты — это ситуация, когда один слайс импортирует из другого слайса на том же слое. Обычно это запрещено [правилом импорта для слоёв][import-rule-on-layers], но часто есть реальные причины, чтоб сделать кросс-импорт. Например, в реальном мире бизнес-сущности часто ссылаются друг на друга, и лучше отразить эти отношения в коде, а не пытаться избавиться от них.
+Кросс-импорты — это ситуация, когда один слайс импортирует из другого слайса на том же слое. Обычно это запрещено [правилом импорта для слоёв][import-rule-on-layers], но часто есть реальные причины, чтобы сделать кросс-импорт. Например, в реальном мире бизнес-сущности часто ссылаются друг на друга, и лучше отразить эти отношения в коде, а не пытаться избавиться от них.
 
 Для этой цели существует особый вид публичного API, также известный как `@x`-нотация. Если у вас есть сущности A и B, и сущность B должна импортировать из сущности A, то сущность A может объявить отдельный публичный API только для сущности B.
 
@@ -45,7 +45,7 @@ export * from "./model/comments";  // 💩 это плохая практика
             - `📄 B.ts` — специальный публичный API только для кода внутри `entities/B/`
         - `📄 index.ts` — обычный публичный API
 
-Затем код внутри `entities/B/` может импортировать из `entities/A/@x/B`:
+Затем код внутри `entities/B/` может быть импортирован из `entities/A/@x/B`:
 
 ```ts
 import type { EntityA } from "entities/A/@x/B";
@@ -141,11 +141,11 @@ import { TextField } from '@/shared/ui/text-field';
 
 Есть несколько вещей, которые вы можете сделать, чтобы справиться с этой проблемой:
 
-1. То же самое, что и в разделе "Большие бандлы и неработающий tree-shaking в Shared" — создайте отдельные индексные файлы для каждого компонента/библиотеки в shared/ui и shared/lib вместо одного большого
+1. То же самое, что и в разделе "Большие бандлы и неработающий tree-shaking в Shared" — создайте отдельные индексные файлы для каждого компонента/библиотеки в `shared/ui` и `shared/lib` вместо одного большого
 2. Избегайте наличия индексных файлов в сегментах на слоях, которые имеют слайсы.  
    Например, если у вас есть индекс для фичи "comments", `📄 features/comments/index.js`, нет смысла иметь еще один индекс для `ui` сегмента этой фичи, `📄 features/comments/ui/index.js`.
 3. Если у вас очень большой проект, есть большая вероятность, что ваше приложение можно разделить на несколько больших кусков.  
-   Например, у Google Docs очень разные обязанности для редактора документов и для файлового браузера. Вы можете создать монорепозиторий, где каждый пакет является отдельным корнем FSD со своим набором слоев. Некоторые пакеты могут иметь только слои Shared и Entities, другие могут иметь только Pages и App, а некоторые могут включать свой небольшой Shared, но при этом использовать большой Shared из другого пакета.
+   Например, у Google Docs зона ответственности для редактора документов и для файлового браузера сильно отличаются. Вы можете создать монорепозиторий, где каждый пакет является отдельным корнем FSD со своим набором слоев. Некоторые пакеты могут иметь только слои Shared и Entities, другие могут иметь только Pages и App, а некоторые могут включать свой небольшой Shared, но при этом использовать большой Shared из другого пакета.
 
    <!-- TODO: add a link to a page that explains this in more detail (when one will exist) -->