Russian Translation

docs/Concepts/access-controller.md

@@ -1,5 +1,5 @@
 ---
-title: 🔒 Access Controller
+title: 🔒 Контроллер Доступа
 excerpt: ''
 deprecated: false
 hidden: false
@@ -12,27 +12,25 @@ next:
 ---
 <Image align="center" src="https://files.readme.io/ff607ff-Screenshot_2024-01-23_at_14.30.19.png" />
 
-Access Controller manages all permission-related states and permission checks in Story Protocol. In particular, it maintains the *Permission Table* and *Permission Engine* to process and store permissions. IPAccount permissions are set by the IPAccount owner.
+Контроллер доступа управляет всеми состояниями и проверками разрешений в Story Protocol. В частности, он поддерживает *таблицу разрешений* и *движок разрешений* для обработки и хранения прав. Разрешения IPAccount устанавливаются владельцем IPAccount.
 
-## Permission Table
+## Таблица разрешений
 
-### Permission Record
+### Журнал Разрешений
 
 | IPAccount  | Signer (caller) | To (only module) | Function Sig | Permission |
 | ---------- | --------------- | ---------------- | ------------ | ---------- |
 | 0x123..111 | 0x789..222      | 0x790..333       | 0xAaAaAaAa   | Allow      |
 | 0x123..111 | 0x789..222      | 0x790..333       | 0xBBBBBBBB   | Deny       |
 | 0x123..111 | 0x789..222      | 0x790..333       | 0xCCCCCC     | Abstain    |
 
-Each record defines a permission in the form of the **Signer** (caller) calling the **Func** of the **To** (module) on behalf of the **IPAccount**.
+Каждая запись определяет разрешение (**Permission**) в виде вызвавшего адреса (**Signer**), который вызывает функцию (**Func**) модуля (**To**) от имени IPAccount.
 
-The permission field can be set as "Allow," "Deny," or "Abstain." Abstain indicates that the permission decision is determined by the upper-level permission.
+Поле разрешения может быть установлено как: "Allow," "Deny," или "Abstain." Abstain - воздержаться (решение о разрешении принимается на уровне выше).
 
-### Wildcard
+### Поддержка универсальных шаблонов (Wildcard)
 
-Wildcard is also supported when defining permissions; it defines a permission that applies to multiple modules and/or functions.
-
-With wildcards, users can easily define a whitelist or blacklist of permissions.
+Шаблоны разрешений (wildcards) позволяют определить права, применимые сразу к нескольким модулям и/или функциям. Это упрощает создание списков разрешений (whitelist) или запрещений (blacklist).
 
 <Table>
   <thead>
@@ -106,20 +104,22 @@ With wildcards, users can easily define a whitelist or blacklist of permissions.
   </tbody>
 </Table>
 
-The above example shows that the signer (0x789...) is unable to invoke any functions of the module (0x790...) on behalf of the IPAccount (0x123...).
+В примере (0x789..222) не может вызывать функции модуля (0x790..333) от имени IPAccount (0x123..111).
+
+Другими словами, IPAccount запретил адресу вызов функций в модуле 0x790...333
 
-In other words, the IPAccount has blacklisted the signer from calling any functions on the module 0x790...333
 
-* Supported wildcards:
+* Поддерживаемые универсальные шаблоны:
 
-| Parameter                  | Wildcard   |
+| Параметр                | Шаблон   |
 | -------------------------- | ---------- |
 | Func                       | bytes4(0)  |
 | Addresses (IPAccount / To) | address(0) |
 
-### Permission Prioritization
+### Приоритет разрешений
+
+Более конкретные разрешения имеют приоритет над общими.
 
-Specific permissions override general permissions.
 
 <Table>
   <thead>
@@ -215,28 +215,29 @@ Specific permissions override general permissions.
   </tbody>
 </Table>
 
-The above shows that the signer (0x789...) is not allowed to call any functions of the module (0x790...) on behalf of IPAccount (0x123...), except for the function 0xCCCCDDDD
+Пример показывает что (0x789..222) не может вызывать функции модуля (0x790..333), кроме функции 0xCCCCDDDD.
+
+Однако, (0x789..222) может вызывать любые функции других модулей от имени IPAccount (0x123..111).
 
-Furthermore, the signer (0x789...) is permitted to call all other modules on behalf of IPAccount (0x123...).
 
 <br />
 
-## Call Flows with Access Control
+## Потоки вызовов с контролем доступа
 
-There exist three types of call flows expected by the Access Controller.
+Существует три типа потоков вызовов, которые проверяются Контроллером доступа:
 
-1. An IPAccount calls a module directly.
-2. A module calls another module directly.
-3. A module calls a registry directly.
+1. IPAccount вызывает модуль напрямую.
+2. Модуль вызывает другой модуль.
+3. Модуль вызывает реестр.
 
-### IPAccount calling a Module directly
+### IPAccount вызывает модуль напрямую
 
-* IPAccount performs a permission check with the Access Controller.
-* The module only needs to check if the `msg.sender` is a valid IPAccount.
+* IPAccount проверяет разрешения через Контроллер Доступа.
+* Модуль проверяет только, является ли `msg.sender` валидным IPAccount.
 
 When calling a module from an IPAccount, the IPAccount performs an access control check with AccessController to determine if the current caller has permission to make the call. In the module, it only needs to check whether the transaction `msg.sender` is a valid IPAccount.
 
-`AccessControlled` provide a modifier `onlyIpAccount()` helps to perform the access control check.
+`AccessControlled` предоставляет метод `onlyIpAccount()` который помогает проверить доступ.
 
 ```solidity Solidity
 contract MockModule is IModule, AccessControlled {
@@ -248,33 +249,33 @@ contract MockModule is IModule, AccessControlled {
 
 <Image align="center" src="https://files.readme.io/6a835ae-Screenshot_2024-01-22_at_17.18.49.png" />
 
-## Module calling another Module
+## Модуль вызывает другой модуль
 
-* The callee module needs to perform the authorization check itself.
+* Модуль, который вызывает другой модуль, должен выполнить проверку доступа самостоятельно.
 
-When a module is called directly from another module, it is responsible for performing the access control check using AccessController. This check determines whether the current caller has permission to make the call to the module.
+Когда модуль вызывает другой модуль, он отвечает за проверку контроля доступа через Контроллер Доступа. Эта проверка определяет, имеет ли текущий вызывающий право вызывать функции другого модуля.
 
-`AccessControlled` provide a modifier `verifyPermission(address ipAccount)` helps to perform the access control check.
+`AccessControlled` предоставляет метод `verifyPermission(address ipAccount)` который помогает проверить доступ.
 
 ```coffeescript Solidity
 contract MockModule is IModule, AccessControlled {
     function callFromAnotherModule(address ipAccount) external verifyPermission(ipAccount) returns (string memory) {
         if (!IAccessController(accessController).checkPermission(ipAccount, msg.sender, address(this), this.callFromAnotherModule.selector)) {
 		        revert Unauthorized();
         }
-			  // do something
+			  // сделать что то
     }
 }
 ```
 
 <Image align="center" src="https://files.readme.io/767f852-Screenshot_2024-01-22_at_17.19.07.png" />
 
-## Module calling Registry
+## Модуль вызывает реестр (Registry)
 
-* The registry performs the authorization check by calling AccessController.
-* The registry authorizes modules through set global permission
+* Реестр выполняет проверку авторизации через Контроллер Доступа.
+* Разрешения задаются глобально через администратора.
 
-When a registry is called by a module, it can perform the access control check using AccessController. This check determines whether the callee module has permission to call the registry.
+Когда модуль вызывает реестр, реестр выполняет проверку контроля доступа через Контроллер Доступа. Эта проверка подтверждает, что модуль имеет право вызывать функции реестра.
 
 ```solidity Solidity
 // called by StoryProtocl Admin
@@ -288,13 +289,13 @@ contract MockRegistry {
         if (!IAccessController(accessController).checkPermission(address(0), msg.sender, address(this), this.registerAction.selector)) {
 		        revert Unauthorized();
         }
-			  // do something
+			  // сделать что то
     }
 }
 ```
 
 <Image align="center" src="https://files.readme.io/3d24a42-Screenshot_2024-01-24_at_09.45.06.png" />
 
-> 📘 The IPAccount's permissions will be revoked upon transfer of ownership.
+> 📘 Разрешения IPAccount аннулируются при передаче права собственности.
 >
-> The permissions associated with the IPAccount are exclusively linked to its current owner. When the ownership of the IPAccount is transferred to a new individual, the existing permissions granted to the previous owner are automatically revoked. This ensures that only the current, legitimate owner has access to these permissions. If, in the future, the IPAccount ownership is transferred back to the original owner, the permissions that were initially revoked will be reinstated, restoring the original owner's access and control.
+> Права, связанные с IPAccount, принадлежат только текущему владельцу. При передаче IPAccount новому владельцу все ранее предоставленные разрешения автоматически аннулируются. Если право собственности возвращается прежнему владельцу, его первоначальные разрешения восстанавливаются.

docs/Concepts/concepts-faq.md

@@ -1,16 +1,17 @@
 ---
-title: ❓ Concepts FAQ
-excerpt: Common technical questions related to our protocol documentation.
+title: ❓ FAQ Концепций
+excerpt: Распостранённые вопросы по нашей документации
 deprecated: false
 hidden: false
 metadata:
-  title: ''
-  description: ''
+  title: ""
+  description: ""
   robots: index
 next:
-  description: ''
+  description: ""
 ---
-## *"What is the difference between License Tokens, Royalty Tokens, and Revenue Tokens?"*
+
+## _"В чём различие между Токенами Лицензии, Токенами Роялти и Токенами Дохода?"_
 
 <Table align={["left","left","left","left"]}>
   <thead>
@@ -20,76 +21,78 @@ next:
       </th>
 
       <th style={{ textAlign: "left" }}>
-        License Tokens
+        Токены Лицензии
       </th>
 
       <th style={{ textAlign: "left" }}>
-        Royalty Tokens
+        Токены Роялти
       </th>
 
       <th style={{ textAlign: "left" }}>
-        Revenue Tokens
+        Токены Дохода
       </th>
     </tr>
+
   </thead>
 
   <tbody>
     <tr>
       <td style={{ textAlign: "left" }}>
-        **Module**
+        **Модуль**
       </td>
 
       <td style={{ textAlign: "left" }}>
-        [📜 Licensing Module](doc:licensing-module)
+        [📜 Модуль Лицензирования](doc:licensing-module)
       </td>
 
       <td style={{ textAlign: "left" }}>
-        [💸 Royalty Module](doc:royalty-module)
+        [💸 Модуль Роялти](doc:royalty-module)
       </td>
 
       <td style={{ textAlign: "left" }}>
-        [💸 Royalty Module](doc:royalty-module)
+        [💸 Модуль Роялти](doc:royalty-module)
       </td>
     </tr>
 
     <tr>
       <td style={{ textAlign: "left" }}>
-        **Explanation**
+        **Объяснение**
       </td>
 
       <td style={{ textAlign: "left" }}>
-        An ERC-721 NFT that gets minted from an IP Asset with specific license terms. It is essentially the license you hold that gives you access to use the associated IP Asset based on the terms in the License Token.  
+       NFT стандарта ERC-721, который выпускается на основе IP-актива с определенными условиями лицензии. Это, по сути, ваша лицензия, которая предоставляет доступ к использованию связанного IP-актива на условиях, указанных в Токене Лицензии.
 
-        A License Token is burned when it is used to register an IP Asset as a derivative of another.
+         Токен Лицензии сжигается, когда он используется для регистрации IP-актива в качестве производного от другого актива.
       </td>
 
       <td style={{ textAlign: "left" }}>
-        Each IP Asset has 100,000,000 Royalty Tokens associated, where each token represents the right of whoever owns them to claim 0.000001% of the gains ("*Revenue Tokens*") deposited into the IPA's Royalty Vault.
+        Каждый IP-актив связан с 100 000 000 Токенов Роялти, где каждый токен предоставляет владельцу право претендовать на 0,000001% прибыли , которая поступает в Хранилище Роялти IP.
       </td>
 
       <td style={{ textAlign: "left" }}>
-        These are the tokens that are actually used for payment (ex. ETH, USDC, etc).  
+        Это токены, которые используются для фактических выплат (например, ETH, USDC и т.д.).
 
-        "*Royalty Tokens*" are used to claim these Revenue Tokens when an IP Asset earns them.
+        *"Токены Роялти"* используются для получения этих Токенов Дохода, если IP-актив зарабатывает их.
       </td>
     </tr>
 
     <tr>
       <td style={{ textAlign: "left" }}>
-        **Associated Docs**
+        **Связанные Документы**
       </td>
 
       <td style={{ textAlign: "left" }}>
-        [License Token](doc:license-token)
+        [Токен Лицензии](doc:license-token)
       </td>
 
       <td style={{ textAlign: "left" }}>
-        [IP Royalty Vault](doc:ip-royalty-vault)
+        [Хранилище Роялти IP](doc:ip-royalty-vault)
       </td>
 
       <td style={{ textAlign: "left" }}>
-        [IP Royalty Vault](doc:ip-royalty-vault)
+        [Хранилище Роялти IP](doc:ip-royalty-vault)
       </td>
     </tr>
+
   </tbody>
 </Table>