docs(naming): refactored typos

i18n/en/docusaurus-plugin-content-docs/current/about/understanding/naming.md

@@ -29,15 +29,13 @@ Naming conflicts can occur when terms used in the FSD methodology overlap with t
 
 For example, a developer seeing the word process in the code will spend unnecessary time trying to understand which process they are talking about.
 
-When communicating within the development team, when saying the word process, everyone involved should clearly understand what we're talking about, the process as a business entity or the process from FSD.
+These **collisions can disrupt the development process**, as developers may spend extra time trying to figure out exactly what they are talking about.
 
-When communicating with the business, developers sometimes use technical terms that the business isn't familiar with. So a developer using the term process to refer to a process from FSD will introduce a misunderstanding into the conversation which may require additional time to clarify.
+When the project glossary contains terminology specific to FSD, it is critical to exercise caution when discussing these terms with the team and non-technical stakeholders.
 
-<!-- TODO: think of examples for other terms -->
+To communicate effectively with the team, it is recommended that the abbreviation "FSD" be used to prefix the methodology terms. For example, when talking about a process, you might say, "We can put this process at the FSD level."
 
-These **conflicts can disrupt the development process** because developers may spend extra time trying to figure out exactly what the conversation is about.
-
-In addition, when communicating with the business, it is important to be aware of any technical terms that may be unfamiliar to non-technical stakeholders. Using such terms can lead to misunderstandings that may take additional time to clarify.
+Conversely, when communicating with non-technical stakeholders, it is best to limit the use of FSD terminology and refrain from mentioning the internal structure.
 
 ## See also {#see-also}
 

i18n/ru/docusaurus-plugin-content-docs/current/about/understanding/naming.md

@@ -17,7 +17,7 @@ sidebar_position: 4
 - "app", "process", "page", "feature", "entity", "shared" как имена слоев,
 - "ui', "model", "lib", "api", "config" как имена сегментов.
 
-Оригинальные названия очень важны, чтобы предотвратить путаницу среди членов команды и новых разработчиков, присоединяющихся к проекту. Использование уникальных имен также помогает при обращении за помощью к сообществу.
+Оригинальный нейминг очень важен, чтобы предотвратить путаницу среди членов команды и новых разработчиков, присоединяющихся к проекту. Использование уникальных имен также помогает при обращении за помощью к сообществу.
 
 ## Конфликты нейминга {#when-can-naming-interfere}
 
@@ -29,15 +29,13 @@ sidebar_position: 4
 
 Например, разработчик, увидев слово процесс в коде, будет тратить лишнее время на понимание, о каком процессе идет речь.
 
-Общаясь внутри команды разработчиков, говоря слово процесс, все участники разговора должны четко понимать о чем идет речь, о процессе как бизнес сущности или о процессе из FSD.
-
-Общаясь с бизнесом, разработчики иногда употребляют технические термины с которыми бизнес не знаком. Так разработчик, употребив термин процесс, имея в виду процесс из FSD, внесет непонимание в разговор, что может потребовать дополнительного времени на разъяснение.
+Эти **коллизии могут нарушить процесс разработки**, поскольку разработчики могут потратить дополнительное время, пытаясь понять, о чем именно идет речь.
 
-<!-- TODO: подумать над примерами для других терминов -->
+Когда глоссарий проекта содержит терминологию, характерную для FSD, крайне важно проявлять осторожность при обсуждении этих терминов с командой и нетехническими заинтересованными сторонами.
 
-Эти **коллизии могут нарушить процесс разработки**, поскольку разработчики могут потратить дополнительное время, пытаясь понять, о чем именно идет речь.
+Чтобы эффективно общаться с командой, рекомендуется использовать аббревиатуру "FSD" для префиксации терминов методологии. Например, когда речь идет о процессе, можно сказать: "Мы можем поместить этот процесс на уровень features FSD".
 
-Кроме того, при общении с бизнесом важно знать любые технические термины, которые могут быть незнакомы нетехническим заинтересованным сторонам. Использование таких терминов может привести к недоразумениям, на разъяснение которых может потребоваться дополнительное время.
+И наоборот, при общении с нетехническими заинтересованными сторонами лучше ограничить использование терминологии FSD и воздержаться от упоминания внутренней структуры.
 
 ## См. также {#see-also}
 
@@ -49,4 +47,4 @@ sidebar_position: 4
 [disc-model]: https://github.com/feature-sliced/documentation/discussions/68
 [disc-naming]: https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-464894
 [disc-processes]: https://github.com/feature-sliced/documentation/discussions/20
-[disc-src]: https://github.com/feature-sliced/documentation/discussions/16
+[disc-src]: https://github.com/feature-sliced/documentation/discussions/16